W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: draft-ietf-httpbis-p6-cache-06

From: Adrien de Croy <adrien@qbik.com>
Date: Wed, 27 May 2009 17:37:47 +1200
Message-ID: <4A1CD1AB.7050005@qbik.com>
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
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.



Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Wednesday, 27 May 2009 05:35:05 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC