mod_gzip - serving compressed content by the Apache webserver - Page 3
Author: Michael Schröpl
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 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
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 5.5 rsp. 6.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.