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

Re: Clarifying Content-Location (Issue 136)

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 5 Oct 2009 22:31:25 -0700
Message-Id: <255D0340-18AE-457E-9BEE-D461120359D5@gbiv.com>
Cc: "'Mark Nottingham'" <mnot@mnot.net>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'Robert Brewer'" <fumanchu@aminus.org>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
To: Brian Smith <brian@briansmith.org>
On Oct 5, 2009, at 9:58 PM, Brian Smith wrote:

> Mark Nottingham wrote:
>> I don't think a new issue is necessary; IMO it's a stretch to say  
>> that
>> the 2616 text requires servers to have separate URIs for different
>> variants, and certainly that wasn't in 2068 (see issue text).
>
> I don't get what you mean. Are you saying it is OK to use the same
> Content-Location for multiple variants of the same resource? If so,  
> then
> what is the point of Content-Location? And, in particular, what is  
> the point
> of saying that servers SHOULD return Content-Location when there are
> multiple variants, if the Content-Location of those variants could  
> all be
> the same as the Request-URI?

Content-Location is for identifying the resource for which the
message payload is a representation.  It does not exist for the
sake of caching.  It will not go away even if caching no longer
mentions it, the spec no longer refers to variants, and the
requirements associated with variants are removed.

Cache invalidation after a successful PUT, POST, or DELETE is
a simple optimization.  It is used in practice for the request URI.
I don't know if it is used in practice for a Content-Location that
does not match the request URI.  Maybe we should check that.
IIRC, that was a late addition to HTTP/1.1.

The base-setting effect was for MIME, MHTML, and message archival.
The only thing we can change is that it does not apply for HTTP.

So, please, if you have specific changes to the document, then
be specific about which sentences need to be removed or fixed.
Please stop ranting about removing the field altogether,
since all that does is interfere with seeing what needs to
be changed in the draft.

....Roy
Received on Tuesday, 6 October 2009 05:31:44 GMT

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