Antwort: Re: Antwort: Re: Antwort: Re: Antwort: [Mod_gzip] Vary: header and mod_gzip

Hi Hendryk,

>> Netscape 4.x is
>> - using HTTP/1.0 _and_
>> - sending "Accept:encoding: gzip"
>> - _and_ lying about its abilities.
>> Great combination, eh? ;-)

> Not a problem. You just blacklist the browser.

> There is a problem if you find that a browser misbehaves in certaion
> conditions by advertising capabilities it cannot handle but you do not
> want to blacklist the browser version.

which is exactly the case with Netscape 4.

This UserAgent can perfectly display gzipped HTML.

But it cannot uncompress gzipped CSS and JavaScript if
requested as a separate file (it _can_ handle CSS and
JavaScript inside compressed HTML documents as a whole).
I address this by using SSI to bundle these file parts
together - which is more effective than caching the CSS
files, because most browsers don't trust my "Expires:"
headers and always unnecessarily revalidate cache con-
tents, then sending and receiving HTTP headers being a
lot _larger_ than the file content in question.
There were times when 40% of all HTTP requests on my
server were Status 304 - could anyone please tell the
users how to correctly configure their Cache strategy
to "automatic"? This would help _a_lot_.

And even worse, it cannot _print_ gzipped HTML - even
though it perfectly rendered it! - because the printing
function seems to fetch its input from the browser cache
where the file resides in uncompressed form and forgets
to decompress it once more ...

Netscape 4 is certainly aware of the gzipped nature of
the cache file. You can do the following:
- Start Netscape 4
- clear its disk cache
- let it display some gzipped HTML file, with no other
  items included (no images or CSS etc.).
- close Netscape 4.
Now move into the Netscape Cache directory. You will
find two files:
- One of an arbitrary name, containing the gzipped
  content of the HTML file.
- a file named "fat.db" containing the cache TOC list.
Open this and scroll down, you will find a (binary)
entry for this file, and the MIME type and the string
"gzip".
So even the Cache structure of Netscape 4 knows about
content-encoding - but they simply forget about this in
a fatal series of cases, like printing. Even the "Print
Preview" function of Netscape 4 will show garbage.

But I don't want to blacklist Netscape 4, as 25% of my
visitors ar running this thingy and the compression
factors for large tables in HTML are in the range of
95-97%. This is essential.
Therefore I have to use the full range of mod_gzip's
configuration skills to exclude certain MIME types
(URI extensions don't reliably provide what I need)
rather than simply exclude the broken browser as a
whole.

And the printing is an unresolved problem - our customers
know about this, but it still doesn't make them upgrade
their browsers.
Greetings, Michael
Received on Wed Aug 28 2002 - 08:29:39 MDT