Re: [Mod_gzip] Vary: header and mod_gzip

From: Henrik Nordstrom <hno@dont-contact.us>
Date: Mon, 26 Aug 2002 12:28:06 +0200

Robert Collins wrote:
> > And this is as it should be. I am not sure you are aware of it
> > but there are, in fact, a number of major HTTP 1.0 legacy
> > browsers out there that pre-date the requirement for an
> > 'Accept-encoding:' field but they are, in fact, perfectly capable
> > of decompressing any response that has 'Content-encoding: gzip'.
> > Some old versions of UNIX command line LYNX browser come to mind.
>
> Thanks, but I am aware of that.

And this is again what Vary is designed to solve. In such case the server
negotiated response varies based on User-Agent, and the HTTP server
performing this content negotiation SHOULD include User-Agent in the Vary
header to tell intermediate caches that the response varies depending on the
User-Agent used by the user.

Intermediate caches not supporting Vary will either
a) Still cache the object, as they know nothing about Vary
b) Not cache the object, as they know about responses varying depending on the
request type and that they are yet incapable of supporting caching of such
objects. (Squid-2.4 and earlier is in this category)

Also, it is higly recommended that a HTTP server performing compression etc
makes proper use of ETag and If-None-Match to identify the different types of
responses. For mod_gzip this involves one ETag for uncompressed replies and
another ETag for compressed replies. This allows a cache to learn the
variance rules set by your HTTP server (Note: If-None-Match support in Squid
is scheduled for Squid-2.6).

If mod_proxy is deciding upon Accept-Encoding AND User-Agent, then it SHOULD
include a "Vary: Accept-Encoding, User-Agent" header in the reply, and it is
strongly recommended to support ETag and If-None-Match as described above for
best operation with intermediary caches.

It is perfectly OK if mod_gzip has options to disable the use of Vary to
improve interoperability with old caches, but this should not be the default
setting for quite obvious reasons. For all users sake it is better if you
recommend the user to use a cache supporting caching of Vary objects.

sidenote: HTTP compliance requires all SHOULD to be implemented. Conditional
compliance requires the ommissions to be documented.

Regards
Henrik
Received on Mon Aug 26 2002 - 04:28:21 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:16:08 MST