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

Adrien de Croy wrote:
> 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.

I believe the idea is that it isn't for caches to override or police
the origin server's policy, but to provide a generic caching mechanism
that supports negotiation, and let the origin server implement the
negotiation policy however it likes.

That is much more extensible to the future, and works with all request
headers, including types of negotation which aren't mentioned in any
spec.

I don't see any advantage in making the cache "smarter" than this, and
several disadvantages.

For example, imaging a server which responds with this text
as a diagnostic service:

    HTTP/1.1 200 UK
    Vary: Content-Language
    Content-Type: text/html
    Etag: 5346593659365

    <html><head></head><body>

    Thank you for your request.<br>
    Your request provided the following language list: "en-nz, fr".

    </body></html>

I think that's a legitimate cacheable response, and one where you
would want the origin server to be consulted when a request comes
along with Content-Language in a different order.

-- Jamie

Received on Sunday, 7 June 2009 23:47:34 UTC