- From: Adrien de Croy <adrien@qbik.com>
- Date: Wed, 27 May 2009 17:37:47 +1200
- To: Brian Smith <brian@briansmith.org>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Adrien de Croy wrote: > > > Brian Smith wrote: >> A cached response can always be returned unless its Vary header says it >> can't be. If some responses included a Vary header and then a later >> cacheable response doesn't include one (for the same resource), then the >> later response will effectively replace all the other cached responses >> because of the "most recent" rule. >> >> > I can see that a later one would always be served by the cache, > however existing older ones could still be revalidated if say the > client requested revalidation, or the freshest one expired. Any time > a revalidation is done, the cache could indicate all ETags for the > URI. At that point, an older one could be selected by the origin > server, which then would become the newest one for subsequent requests. > > Seems to me this would lead to weird results, esp with multiple > language versions of the same URI. > also, the matching rules for matching on selected headers are quite unintuitive. the rule states that they must be identical except for whitespace and combining headers. However order therefore is still important, so matching between Content-Language: en-nz, fr and Content-Language: fr, en-nz would fail, even though logically these are identical since order is not significant in the spec. I can understand this makes matching simpler (normalise and string compare), and probably shields against arbitrary selection algorithms (e.g. order-based) being used by the origin server, but it's not clear from the spec as to why, and anyone wanting to do things a bit "smarter" may consider doing a different sort of match with potentially questionable results. regards Adrien -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Wednesday, 27 May 2009 05:35:05 UTC