Which browsers can handle Content-Encoding: gzip ?

Netscape 3 Netscape 4 Netscape 6 & 7 and Mozilla Adobe Acrobat
Microsoft Internet Explorer Lynx Opera until version 4 Opera version 5 and up

Netscape and Mozilla

Netscape Navigator 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 Communicator 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

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 version 4.0 and up

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.

Microsoft published a problem report for the Internet Explorer in den versions arrow5.5 rsp. arrow6.0 when dealing with compressed HTTP content.

When working together with the Adobe Acrobat Reader the Internet Explorer seems to have a problem handling gzip-compressed PDF documents.

Opera

Opera until version 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 version 5 and up

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.

Adobe Acrobat Reader

The Adobe Acrobat Reader for display of PDF documents usually works as a plugin within a browser window.

At least the combination of Acrobat Reader 4.0 and Internet Explorer (browser versions 5.0 and 6.0SP1 have been tested) can make an access to the content of a PDF document fail when transferred in compressed form. The problem seems to be that the browser has to already have this file's content completely decompressed before the plugin may access it ... this seems to be a race condition within the Internet Explorers, i. e. sometimes it works and sometimes it doesn't.

The combination of Acrobat Reader 4.0 and Mozilla can handle gzip compressed PDF documents correctly; the same applies to the combination of Acrobat Reader 4.0 and Opera 7.

(Michael Schröpl, 2003-03-11)