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值拿掉即可.