Elegance

今天用netcat將下列的HTTP command丟到104的server去觀察它吐給我的結果 -------------HTML Command Begin------------------------------------ POST /login.cfm HTTP/1.1 Accept: */* Referer: http://login.104.com.tw/login.cfm Accept-Language: zh-tw Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Host: login.104.com.tw Content-Length: 100 Connection: Keep-Alive Cache-Control: no-cache POST內文略. -------------HTML Command End------------------------------------ Server首先會將HTML原始碼以LZ77演算法壓縮成gz檔(也就是gunzip檔)後再將這個檔拆成好幾個chunk丟給我 我想應該是它的TCP封包分成好幾段傳送，才會有這樣的結果. 所以要了解HTTP處理chunked transfer encoding的方法要去參考RFC2616的第3.6.1的Section有講到這好幾個chunk的格式. Chunked-Body = *chunk last-chunk trailer CRLF chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLF chunk-size = 1*HEX last-chunk = 1*("0") [ chunk-extension ] CRLF chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) chunk-ext-name = token chunk-ext-val = token | quoted-string chunk-data = chunk-size(OCTET) trailer = *(entity-header CRLF) 首先第一個chunk會在HTTP Server Respone後，也就是在0D0A0D0A後開始，先傳一個chunk檔案大小的值給我(這個值是已經轉成16進位， 因此最好先自己再傳成10進位，會比較方便理解)最後這個值會以0D0A結束，後面緊跟著的chunk-data大小就是前面chunk-size指定的長度，然後會再以0D0A結尾，接下來就是下一個chunk的檔案大小值，再來就是用0D0A做結尾，然後按照這方法一直去算下一個chunk 的開頭和結尾處後，最後一個last-chunk的結尾會先有本身結尾的0D0A，還有一個16進位ASCII值為30的阿拉伯數字"0"這個字，最後再以 0D0A0D0A做結束，這樣個別去算每個chunk的範圍，再把這些各別chunk範圍接起來，存成一個.gz的檔案，就可以自己去解壓縮了!! P.S.以上實驗用netcat還有XVI32免費的HEX Editor軟體以及winrar(能解gunzip的解壓軟體都可以)完成!! 註:如果不想要壓縮成gzip可以將HTTP Request的Accept-Encoding header裡的gzip值拿掉即可.