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 many 4.x versions Cascading Style Sheets that are loaded from a separate file by use of the HTML tag
<link rel="stylesheet" type="text/css" href="file name" />
will not be decompressed and thus not evaluated.
In many 4.x versions JavaScript code that is loaded from a separate file by use of the HTML tag
<script type="text/javascript" src="file name" />
will be decompressed and evaluated only if a cache is activated in the browser.
(In case of activated JavaScript in the browser this problem may additionally cause JavaScript error messages if the HTML source code references definitions of the included JavaScript code.)
In many 4.x versions the HTML code of the document will be decompressed before printing the page content only if a cache is activated in the browser; the same applies to the display of the page content in print preview mode.
In many 4.x versions the display of HTML source code of the current documents works correctly only if a cache is activated in the browser. Otherwise an empty screen will be displayed instead of the source code.
In many 4.x versions the correct handling of gzip compressed images may fail in the browser, under circumstances that don't seem to be easily reproducable. (Anyway, images should be optimized manually by using chosing the correct file type, using a minimal color depth for GIF and the like - gzipping an already compressed file format won't lead to an additional gain worth mentioning.)
In the versions 4.06 to 4.08 there are even problems with the processing of JavaScript code inside the <head> section of compressed HTML pages.

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.

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)

Which browsers can handle Content-Encoding: gzip ?