Peter Naulls wrote:
Moreover, it isn't the browser doing the gunzipping - it's
on the browser's request.
Incorrect; it's the client's HTTP implementation that decompresses the
file. In the general case it would be pointless to expand a compressed
file *prior* to sending it over the wire.
Section 3.5: "...Frequently, the entity is stored in coded form,
transmitted directly, and only decoded by the recipient". If this were
not the case, someone has upgraded my broadband connection, since I just
downloaded Autoconf at over 500KiB/sec with only a 1Mbit/sec line!
I notice that NetSurf, like Browse, correctly sets the filetype to "Tar"
though it keeps the ".tar.gz" filename extension. This further indicates
correct behaviour on NetSurf's part, though you could argue it might be a
nice feature to try and spot that the ".gz" ought to be removed. The
"diff.gz" files on the server fetch straight into NetSurf and Browse as
uncompressed plain text, again, what we would expect from HTTP 1.1
content coding. Dumping headers from the server, I see that it is indeed
specifying a content type of application/x-tar.
This is a server configuration error, not a NetSurf bug.
TTFN, Andrew Hodgkinson
Find some electronic music at: All sorts of other bits and pieces at: