First:
I proposed to not only drop that *none*-Etag, but also to send no-cache.
The second is an error. The server should not send no-cache, but let it
to the client and the intermediate caches to decide about caching on the
base of the spec and their configured policy. But I still believe
dropping that *none*-Etag is the best.
Henrik Nordström wrote:
Clietn -> Squid -[internet]-> Apache
the object in question is having a weak ETag but significant freshness
assigned to it via mod_expires or similar.
object gets cached by Squid & client with a weak etag
client later issues an IF-None-Match request to Squid using the weak
ETag. Squid considers the object still fresh and responds with 304.
Objections:
- Squid seems not to take any information from the Etag.
- if the client has the etag and the entity (aka variant), it also has
the freshness information from Expires or max-age. It will not contact
Squid at all.
- is it wise to send an Expires header and an Etag? I don't think so.
These are two alternative ways of cache validation. Using both is
confusing. Which one has preference? An Etag implies an If-(None)-Match
conditional request; what's the use of Expires?
- if a client lost the expires header as well as the confusing Etag and
sends GET If-Unmodified-Since, how would Squid respond? I guess: 304.
So I don't think Squid or the clients will loose anything, when the
invalid Etag is dropped.
There might be a one in a million chance (I don't know how), that this
invalid Etag will save the transfer of an 1 MByte file from Squid to
client. But this is not worth the confusion.
Cheers
Werner
