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

[Robert Collins]

--=-LIRrhXj4M/97o3JM2QaU
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2002-12-09 at 14:36, TOKILEY@aol.com wrote:

Just a note:=20

> What "Vary: *" is actually 'telling' an inline Proxy Cache Server
> could be translated like this...
>=20
> "You can go ahead and cache this response if you choose to
> so you can hand out the same response to the next person=20
> who asks for the same URI... but be advised that if ANY of
> the REQUEST headers from the next person who asks for=20
> this differs in any way from the REQUEST headers associated
> with the CURRENT REQUEST ( the one that produced this
> response ) then do NOT give them this response and you=20
> must come back to the Content Origin Server and let IT
> decide what response this person should get."

The above is wrong.

Vary: *=20
Means that the reponse was calculated on *something* that is not
represented in the REQUEST headers, and thus MUST BE revalidated EVERY
time.=20

Caching is allowed, but only in combination with ETAG validation against
the origin on every request.

> Note that there still is no reason that a Proxy Cache Server
> should NOT go ahead and 'cache' this response even though
> it has "Vary: *" in the RESPONSE headers. "Vary: *" does
> not mean DON'T CACHE IT... it just means that unless the
> next set of REQUEST headers matches perfectly then you
> can't consider this the correct response to the URI request.

Again, Vary: * does NOT mean this. See above.

>... in which case it is still
> OK for the Proxy Cache Server to 'dish out' the cached
> response even though it has "Vary: *" on it.

No, it's NOT.


> Now that SQUID 2.5 is finally not refusing to cache
> ANY "Vary:" responses... I wonder what the policy is
> with regards to "Vary: *" and SQUID 2.5? Will SQUID 2.5
> still treat "Vary: *" as "Expires: -1" and NEVER cache
> those responses or will it, in fact, go ahead and cache
> it on the off chance that it MIGHT be able to use it
> for awhile ( until the Vary: * condition is satisfied ).

Vary * =3D=3D expired -1 =3D=3D max-age=3D0+cache-control:must-revalidate.=20

All three things above have the same impact on shared caches. IIRC squid
will attempt to revalidate Vary: * marked responses. I haven't time to
check the code, or I'd give a more solid answer.

> As far as I know... sending something like "Expires: -1" should
> take precedence over ANY other 'caching rules' and that=20
> response should NEVER be cached by ANYONE... Inline
> Proxy Cache Server or end-point User-Agent (browser).

Old Expires headers DO NOT mean DO NOT CACHE.
It means "Always revalidate".

Cache-control: no-store and no-cache are the only headers that signal to
not save to disk, and not cache at all.
Oh, for HTTP/1.0 there is a  pragma header, but again, it's not
Expires:.

There is a *huge* difference.

Rob


--=-LIRrhXj4M/97o3JM2QaU
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)

iD8DBQA99GB9I5+kQ8LJcoIRAnnzAJ9Ki/r5Om7h6yRqHTWo5AkFy8dYUACfZAG5
bp17ZeVdOsP4RU+txhLsAuM=
=XAqC
-----END PGP SIGNATURE-----

--=-LIRrhXj4M/97o3JM2QaU--