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

Just FYI, we do have an open issue on these lines:
   http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147

Cheers,


On 08/06/2009, at 9:47 AM, Jamie Lokier wrote:

> 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
>


--
Mark Nottingham     http://www.mnot.net/

Received on Monday, 8 June 2009 00:34:03 UTC