Which browsers can handle Content-Encoding: gzip ?

Netscape 3

This browser uses HTTP/1.0. It doesn't send an Accept-Encoding header, thus doesn't request compressed content from a server.

The browser does not yet support the processing of compressed page content. If it receives gzip compressed content, it recognizes that there is an encoding gzip unknown to it (and displays a corresponding message to the user), but after that it displays the compressed page content within the browser windows. Serving compressed content unconditionally (like in statically precompressed documents) this browser isn't good for.

A web server correctly evaluating the Accept-Encoding header is able to serve usable, uncompressed data to the browser.

Netscape 4

This browser uses HTTP/1.0. From version 4.06 on it is sending the header Accept-Encoding: gzip.

Nevertheless the implementation of handling compressed content contains a number of bad errors:

In all these cases Netscape 4 seems to use the received, yet uncompressed version; obviously the invocation of a (surely available) function for content compression simply has been forgotten at the decisive positions.

And some part of the errors described above may only be in effect if the browser's cache has been set to 0 MB and/or switched off - so it seems Netscape 4 is somehow using the browser cache as temporary storage for decompressing ...

Netscape 6 & 7 and Mozilla 0.9.x & 1.x

This browser uses HTTP/1.1. From Netscape 6.2 on (= Mozilla 0.9.4), it is sending the header Accept-Encoding: gzip, deflate, compress;q=0.9.

Mozilla 0.9.9+ und Netscape 7.0PR1 allow the user to define the HTTP version as well as the content of this headers in its configuration; in Mozilla 1.1alpha this function is no longer visible in the preferences but can be defined in the configuration file defaults/pref/all.js (under the name network.http.accept-encoding).

Processing compressed content works if the browser has requested compressed content; otherwise it ignores the HTTP header Content-Encoding: gzip although it would be able to decompress the content.

Microsoft Internet Explorer 4.0, 5.0, 5.5 and 6.0

This browser uses either HTTP/1.0 or HTTP/1.1, depending upon the settings in the internet options. It is sending the header Accept-Encoding: gzip, deflate - but only if using HTTP/1.1.

Processing compressed content works if the browser has requested compressed content; otherwise it ignores the HTTP header Content-Encoding: gzip although it would be able to decompress the content.

Some older versions of the Internet Explorer seem to fire the JavaScript event onLoad already when they have successfully received a JavaScript file referenced within the <head> section instead of waiting for the successful completion of decompressing its content.

Opera 3 and 4

Opera 3.5 does not yet understand compressed content.

From version 4 on Opera is using HTTP/1.1. Opera 4.0beta3 did already try to communicate in compressed form but sent the header TE: deflate, gzip, x-gzip, identity, trailers, i. e. it expected gzip compression to be applied as Transfer Encoding, not as Content Encoding.

Opera 5 and 6

Starting with version 5.12 (or a bit earlier) Opera is sending the header Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0. Processing compressed content works without known problems in versions 5 and up.

Opera 6 (as the single known browser up to now) decompresses gzip-compressed document content even if the server did not call its attention to it by serving the HTTP header Content-Encoding: gzip.

Lynx

Lynx supports gzip-compressed communikation since version 2.6.

The first Lynx versions had to start a separate process using an external gzip -d command for decompressing. This of course leads into problems in case of no gzip command being available.

More recent versions of Lynx (since 1997-08-14, see Lynx 2.8.0 CHANGES file) use the zlib library for decompressing and don't have these problems any more.

(Michael Schröpl, 2002-09-16)