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