Here's a snippet of the response as captured by tshark:
tshark 'port 80 and (dst ubuntuone.com or src ubuntuone.com)' -V -R "http.request || http.response"
"""
Hypertext Transfer Protocol
HTTP/1.1 206 Partial Content\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 206 Partial Content\r\n] [Message: HTTP/1.1 206 Partial Content\r\n] [Severity level: Chat]
[Group: Sequence]
Request Version: HTTP/1.1
Status Code: 206
Response Phrase: Partial Content
Date: Wed, 23 Jan 2013 00:03:32 GMT\r\n
Server: TwistedWeb/10.0.0\r\n
Content-Length: 1001\r\n
[Content length: 1001]
Content-Disposition: inline; filename=Selection_281.png\r\n
Content-Encoding: gzip\r\n
Vary: Accept-Encoding\r\n
Last-Modified: Tue, 08 Feb 2011 11:33:40 GMT\r\n
Content-Range: bytes 0-1000/103567\r\n
ETag: "sha1:0d8a6d5947321c0a207e349f6a91b0d2dc445470;gzip"\r\n
X-Bzr-Revision-Number: 6709\r\n
Content-Type: image/png\r\n
X-Cache: MISS from calamansi.canonical.com\r\n
X-Cache-Lookup: HIT from calamansi.canonical.com:3128\r\n
Via: 1.0 ip-10-38-193-141.ec2.internal:3128, 1.1 calamansi.canonical.com:3128 (squid/2.7.STABLE7)\r\n
Via: 1.1 www.ubuntuone.com\r\n
\r\n
Content-encoded entity body (gzip): 1001 bytes -> 1008 bytes
"""
So a couple things:
1. Your script (actually, the go library that it uses) is declaring that it supports gzip encoding
2. The server is returning 1001 bytes, gzipped, which expand to 1008 bytes (could argue this might be an issue)
3. Note there *is* a Content-Length header in the response. However for some reason it is not printed by the script
I suspect what is happening is that go is automatically handling the gzipped response, but it contains more bytes than Content-Length after being un-gzipped, or something along these lines.
Here's a snippet of the response as captured by tshark:
tshark 'port 80 and (dst ubuntuone.com or src ubuntuone.com)' -V -R "http.request || http.response"
"""
[Message: HTTP/1.1 206 Partial Content\r\n]
[Severity level: Chat] 10.0.0\ r\n Disposition: inline; filename= Selection_ 281.png\ r\n Encoding: gzip\r\n 7321c0a207e349f 6a91b0d2dc44547 0;gzip" \r\n Revision- Number: 6709\r\n canonical. com\r\n canonical. com:3128\ r\n 193-141. ec2.internal: 3128, 1.1 calamansi. canonical. com:3128 (squid/ 2.7.STABLE7) \r\n com\r\n
Hypertext Transfer Protocol
HTTP/1.1 206 Partial Content\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 206 Partial Content\r\n]
[Group: Sequence]
Request Version: HTTP/1.1
Status Code: 206
Response Phrase: Partial Content
Date: Wed, 23 Jan 2013 00:03:32 GMT\r\n
Server: TwistedWeb/
Content-Length: 1001\r\n
[Content length: 1001]
Content-
Content-
Vary: Accept-Encoding\r\n
Last-Modified: Tue, 08 Feb 2011 11:33:40 GMT\r\n
Content-Range: bytes 0-1000/103567\r\n
ETag: "sha1:0d8a6d594
X-Bzr-
Content-Type: image/png\r\n
X-Cache: MISS from calamansi.
X-Cache-Lookup: HIT from calamansi.
Via: 1.0 ip-10-38-
Via: 1.1 www.ubuntuone.
\r\n
Content-encoded entity body (gzip): 1001 bytes -> 1008 bytes
"""
So a couple things:
1. Your script (actually, the go library that it uses) is declaring that it supports gzip encoding
2. The server is returning 1001 bytes, gzipped, which expand to 1008 bytes (could argue this might be an issue)
3. Note there *is* a Content-Length header in the response. However for some reason it is not printed by the script
I suspect what is happening is that go is automatically handling the gzipped response, but it contains more bytes than Content-Length after being un-gzipped, or something along these lines.