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

Re: Clarifying Content-Location (Issue 136)

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 6 Oct 2009 16:30:31 +1100
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-Id: <D4BEF484-9079-4C6B-A009-79FE4213501A@mnot.net>
To: Brian Smith <brian@briansmith.org>
Yep, but it's still fundamentally different, and C-L is still used in  
cache invalidation.


On 06/10/2009, at 4:26 PM, Brian Smith wrote:

> Mark Nottingham wrote:
>> On 06/10/2009, at 3:56 PM, Brian Smith wrote:
>>> http://trac.tools.ietf.org/wg/httpbis/trac/changeset/691
>>
>> The text removed in changeset 691 was very specific to a situation
>> where C-L matched the request URI and the ETag and Date said it was
>> different; it's a very different thing than the invalidation  
>> specified
>> for methods with side effects.
>
> No, here is what it said:
>
>    If a cache receives a successful response whose
>    Content-Location field matches that of an existing stored
>    response for the same Request-URI, whose entity-tag
>    differs from that of the existing stored response, and
>    whose Date is more recent than that of the existing response,
>    the existing response SHOULD NOT be returned in response to
>    future requests and SHOULD be deleted from the cache.
>
> In other words:
>
>    If a cache receives a successful response whose
>    Content-Location field matches the Content-Location field
>    Of an existing stored response for the same request-URI, ...
>
> In particular, note that the cache doesn't compare a Content- 
> Location to a
> Request-URI.
>
> Regards,
> Brian
>
>


--
Mark Nottingham     http://www.mnot.net/
Received on Tuesday, 6 October 2009 05:31:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:12 GMT