lör 2007-12-29 klockan 20:56 +0100 skrev Werner Baumann: > Objections: > - Squid seems not to take any information from the Etag.
Yes it does. It uses the ETag as an resource variant identifier. > - 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. It varies wildly. Mostly due to clients often not having their clocks set right I suppose. > - 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? What? The two is completely unrelated. ETag assigns a resource variant version identifier, unique for that specific version of a resource variant. In a sense similar to Last-Modified, but is not (protocol wise) limited to linearly increasing time at a second granularity, and also uniquely identifies a single variant version of a resource clearly telling caches when two responses to different requests results in the same variant on negotiated objects. Expires says when a returned response can no longer be considered fresh without a conditional cache validation request using If-None-Match/Last-Modified. > - 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. I don't know of any clients using GET If-Unmodified-Since.. only If-Modified-Since / If-None-Match / If-Range. DELETE If-Unmofified-Since I have heard about. > So I don't think Squid or the clients will loose anything, when the > invalid Etag is dropped. Squid will loose it's variant knowledge. Many Mozilla versions will behave somewhat badly on Vary:ing objects due to bug in it's use of If-Modified-Since. and the fixed versions will not cache such objects iirc.. (I haven't folloved the resolution to that bug very closely and may be wrong about it being fixed or how it got fixed) > 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. What confusion are we actually talking about? The risk that someone makes two or more significant updates to a resource within the same second, and that this is important to requests within that same second? Or the bug that Apache contrary to the RFC never matches weak ETags in If-None-Match conditions? Or the WebDAV update problem that proper WebDAV operation really needs a strong ETag from start usable in If-Match? (i.e. PUT, followed by PUT If-Match on update without having to do a GET inbetween). Or the relatewd problem that the specs forbids weak ETags in PUT If-Match even when in real life semantic equivalence is sufficient there and octet equavilence is not that important.. Or the risk that due to Apahces way of dealing with the sub-second update problem in it's ETag generation, cobined with it's inability to later match that ETag in If-None-Match may cause client implementors to make workarounds and assumptions about how Apache deals with ETag, maybe even dropping the weakness if seeing it "upgraded" to a strong one..? Regards Henrik
signature.asc
Description: Detta är en digitalt signerad meddelandedel
