Subject: Re: The document's address

From: Nicholas Shanks <[email-masked]>
Date: Fri, 18 Jan 2013 11:46:58 +0000

On 17 January 2013 19:49, Ian Hickson <[email-masked]> 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.

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

-- 
Nicholas.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 18 Jan 2013 04:23:21 -0800

> given Content-Location for the representation returned, not use the

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.

> there is still time to fix it for 2.0

Not likely in either case,

....Roy