[Mod_gzip] "mod_gzip_send_vary=Yes" disables caching on IE? (1.3.26.1a)

[Robert Collins]

--=-CO4hH0lXcPqWSe7bMYCA
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2002-12-07 at 14:08, TOKILEY@aol.com wrote:

> I still don't understand why in the hell SQUID is going to
> (as you say) "eject ALL of the cached objects" just=20
> because it gets a "Vary:" on an 'encoding' type. That
> simply still violates the "principle of least astonishment"
> for me but this is neither the time or the place for that
> discussion.=20

Well, this place is as good as any for a quick note on that topic:

It's an arbitrary decision. For a given URL, given a choice of one
object that varies on User-Agent (and had string 'foo' for the UA)
('A'), one on Accept-Encoding (and had string 'bar' there) and
User-Agent (recorded with 'foo' again) (object 'B'), and one that
doesn't vary at all (object 'C'), what object *should* squid send back
to a response that has User-Agent 'foo' and Accept-Encoding 'bar' ?
All three match their respective Vary rules.

To avoid such a choice, squid ensures that all the objects in the cache
for a given URL have the same Vary rules.

14.44 states that a cache MAY assume that the same list of headers will
be used for all variants on an object, while the object is fresh, so
this issue has at least been looked at a little.

We MAY do better in the future, if time and resources permit.
=20
> 1. Absolutely NOTHING supports "Transfer-encoding: gzip"
> which would be the REAL answer to these issues. Not
> even SQUID supports it. An attempt was made once some
> years back for SQUID to support it but it was never
> finished and no one wants to 'go there' anymore.

Oh, I have *every* intention of going there. I've a version of squid on
my harddrive that runs TE with gzip, and it is also on the sourceforge
squid branch. There are problems with that version, which we are
currently addressing at an architectural level in squid.

> 2. The HTTP design specs have totally dropped the ball
> when it comes to handling response variants that are
> NOT based on MIME type, but rather, content encodings.
> There just aren't enough options in the protocol to handle
> this all correctly and the ones that ARE there ( Vary, Etag,
> etc. ) are still bound to cause more problems than they solve.

Well, I think you and I disagree there. I think that if implemented, the
HTTP spec covers content encoding of response variants pretty much ok.
Certainly, until it's all implemented, we can't really complain that the
theory is wrong.
=20
Rob


--=-CO4hH0lXcPqWSe7bMYCA
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA98fRuI5+kQ8LJcoIRArD2AKCs9mzi/ZhzCynApaklohp8l7PT1QCfRGwI
y9ZqMbPU66uIeezNB+kth1Q=
=4fb7
-----END PGP SIGNATURE-----

--=-CO4hH0lXcPqWSe7bMYCA--