Re: Problem with cached entries w/ETag and request without If-None-Match header

fre 2009-06-12 klockan 13:02 -0400 skrev Jason Noble:
> I recently ran into a bug on Squid 2.7 regarding cached content with
> ETags. Currently, if all cached entries for a URL include ETags, and a
> request is received for said URL with no If-None-Match header, Squid
> will serve a cached entry. This behavior does not follow RFC 2616. I
> have attached a patch that prevents Squid from serving the cached
> entries in said case here:
> http://www.squid-cache.org/bugs/show_bug.cgi?id=2677
>
> I would appreciate any feedback regarding this patch.

As others have already pointed out it's plain wrong.

Please read "RFC2616 13.6 Caching Negotiated Responses" again for more
details on how this works in HTTP. It's a quite simple and effective
scheme when used right.

In short

Selecting request headers (as indicated by Vary) select which response
may be returned in response to the request. If there is multiple
matching responses then the most recent among them should be used.

Conditional request headers determine if that response is to be a 200,
304 or in case of origin servers only 412.

An unconditional request is just that, and will always respond with the
matching 200 response.

Clients can not select which response to return based on etag, only by
using negotiation request headers as indicated by Vary, such as Accept,
Accept-Language, Accept-Encoding, Cookie etc..

Regards
Henrik
Received on Sun Jun 28 2009 - 20:17:37 MDT