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

Re: Clarifying Content-Location (Issue 136)

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 28 Sep 2009 00:18:30 -0700
Message-Id: <BF3A2DB3-EBAB-40A2-AECC-AF9385DEB868@gbiv.com>
Cc: "'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 Sep 27, 2009, at 11:59 PM, Brian Smith wrote:
> Julian Reschke wrote:
>> Brian Smith wrote:
>>> First, "when it is different than the request resource's URI" is
>>> unnecessary and wrong. Having a Content-Location that is the
>>> same as the request URI is valid and is actually the only safe
>>> use of Content-Location.
>>
>> What use would that be? (assuming we're talking about GET)
>
> Exactly. Content-Location doesn't have any interoperable uses in  
> HTTP. My
> point is that Content-Location is generally safe only when Content- 
> Location
> = Request-URI, but then it is useless, except for its misuse in  
> AtomPub (See
> RFC 5023 to see how Content-Location is used in AtomPub).

It is being used correctly by AtomPub.  The purpose of the field is to
support MIME encapsulation, not HTTP, so the fact that it has only
one remaining usage in HTTP (due to browser bugs) should be no big
surprise.

The section should not say "when it is different than the request
resource's URI" because it is useful for a response to a non-GET
method that wants to indicate that this body is what you would
have received in a 200 response if the request had been a GET on
the content-location URI.  In other words, it saves the client
from having to make a subsequent request for the current state if
the client can trust the server's response, which is almost always
true for non-GET methods and especially when the Content-Location
does match the requested URI.

....Roy
Received on Monday, 28 September 2009 07:19:07 GMT

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