Antwort: RE: Antwort: [Mod_gzip] [ANNOUNCEMENT] mod_gzip 1.3.26.1a

[mod_gzip@lists.over.net]

Hi Bill,


> If I understand the documentation correctly
> (http://www.schroepl.net/projekte/mod_gzip/cache.htm),
> mod_gzip will send a Vary: * header if I specify
> "mod_gzip_min_http 1001". The Vary * header will have the
> effect of disabling all (proxy) caching.

Yes. This is why I would now call the "mod_gzip_min_http"
directive "deprecated".

> And, if I use "mod_gzip_item_exclude reqheader
> 'User-agent: Mozilla/4.0[678]'",

Because of the "Vary:" issue, I tend to no longer exclude
just Netscape 4.06-4.08 now. These are broken badly, and
I won't like to support them any more.
On the other hand, you might want to exclude Netscape 4.x
completely because of other bugs they have. For this see
below.

> mod_gzip will include the user agent in the Vary header.

Yes - if no other "exclude" rule for "file", "uri" or
"handler" fired!
Only the content that is really subject to a negotiation,
i. e. may be served in compressed as well as in uncom-
pressed form, depending on HTTP request headers, will
have to be send with a "Vary:" header, so that a proxy
can handle it correctly. But not those that are never
to be compressed (like images, PDF, ...).

This is the big improvement of mod_gzip 1.3.26.1a - you
can explicitly let all the things be cached that you
decide to never compress at all.
Use "exclude" rules to tell mod_gzip about this - having
no "includes" is _not_ sufficient as of now (the rule
filtering logic needs to be rewritten to get the perfect
solution some day).

> This will also disable caching.

Not even this is absolutely true any more.

Squid 2.5 is out and running, and it _is_ caching the
same URI with compressed and uncompressed content in
parallel. (We have tested this successfully today, with
some M$IE in HTTP/1.0 mode.)
If you are sending the correct "Vary:" header then Squid
will now do its best to cache the content.

But if you talk about older Squid versions, then yes,
they will decline to cache content that is being sent
with a "Vary:" header.
On the other hand, if you are lying to such a proxy,
then it will serve the compressed content from its cache
to browsers that cannot handle it, not only Netscape 4,
but all M$IE versions that are running in HTTP/1.0 mode!
There is a reason why Christian has implemented all this
"Vary:" stuff into mod_gzip ...

So, to sum up the options that you have:

a) Don't send "Vary:", any lie to all proxies. Don't do it.

b) Use mod_gzip_min_http. This will indeed disable caching.
   Still not good.

c) Use "mod_gzip_item_exclude reqheader". Much better.

d) Additionally write as many "mod_gzip_item_exclude"
   rules as you need, to make mod_gzip detect cases in
   which it may get away without a "Vary:" header.
   As of now, mod_gzip will not yet detect that a request
   has been declined because of no "include" firing - it
   will only let an "exclude" be the case to suppress the
   "Vary:" header. So you can help the situation by writing
   proper filter rules.
   Combine mod_gzip rules and "Expires:" rsp. "Cache-Control:"
   header generation in your Apache configuration ...

e) Do you really need to exclude Netscape 4? Think of other
   ways for doing it.
   What about excluding JS and CSS files? They are small,
   this might be an option. Netscape 4 _can_ handle com-
   pressed HTML, it just cannot print it. Maybe you need
   some "printable version" of your pages that are most
   likely to be printed; this might be done by providing
   some alias name or UNIX symbolic link for the file
   with a name pattern that would match to some "exclude"
   directive.
   What about server-side-include these files into HTML?
   You won't be able to cache them separately, but on the
   other side you will save HTTP-304 requests of browsers
   whose cache validation algorithm has been configured
   to "always". And you will then be able to even send
   compressed CSS and JavaScript to Netscape 4, inside a
   HTML document.


Regards, Michael