W3C home > Mailing lists > Public > www-html@w3.org > January 2013

Re: The document's address

From: Roy T. Fielding <fielding@gbiv.com>
Date: Fri, 18 Jan 2013 04:23:21 -0800
Cc: Ian Hickson <ian@hixie.ch>, Julian Reschke <julian.reschke@greenbytes.de>, W3 HTML Public List <www-html@w3.org>, IETF HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <E1445F85-E1EA-4B2E-AE96-62361EFC025D@gbiv.com>
To: Nicholas Shanks <nickshanks@gmail.com>
On Jan 18, 2013, at 3:46 AM, Nicholas Shanks wrote:

> On 17 January 2013 19:49, Ian Hickson <ian@hixie.ch> wrote:
>> On Wed, 21 Nov 2012, Nicholas Shanks wrote:
>>> 
>>> The definition of the document's address:
>>> http://dev.w3.org/html5/spec/dom.html#the-document's-address
>>> doesn't mention if the Content-Location header should be taken into account.
>> 
>> My understanding is that Content-Location is essentially dead:
>> 
>>   http://trac.tools.ietf.org/wg/httpbis/trac/ticket/154
> 
> That ticket says:
> 
> "2) HTTP's advice to set Content-Location when doing server-driven
> content negotiation results in links that are relative to a negotiated
> resource, rather than the desired (non-negotiated) URI."
> 
> 
> I find this is a real pain and wish I could turn it off in Apache. I
> only want Content-Location to be present when I intend it to be, e.g I
> want to do this:
> 
> POST /collection-uri
> { representation of new resource }
> 
> 201 Created
> Content-Location: /resource-uri
> { representation of created resource }
> 
> and have caches and the address in the browser's address bar use the
> given Content-Location for the representation returned, not use the
> request URI.

Which would be a security hole if /collection-uri and /resource-uri
are controlled by different owners.  In practice, there is no way
for clients to know the scope of resource ownership.

Search for "cache poisoning" for more explanation.

> But instead I have to do this:
> 
> POST /collection-uri
> { representation of new resource }
> 
> 303 Go Here
> Content-Location: /resource-uri
> 
> GET /resource-uri
> 
> 200 OK
> { representation of created resource }
> 
> 
> requiring an extra round-trip and losing the semantics of a 201
> response. If HTTP could be changed so that content negotiation MUST
> NOT cause C-L: header to be added, and HTTP software patched to obey
> this, then there may be scope in the future for requiring UAs to
> display the Content-Location rather than the request URI, once servers
> have had their software updated. HTTP 1.x may be a lost cause, but
> there is still time to fix it for 2.0

Not likely in either case,

....Roy
Received on Friday, 18 January 2013 12:23:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 18 January 2013 12:23:45 GMT