Comment 6 for bug 1103136

Revision history for this message
Sidnei da Silva (sidnei) wrote :

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.