Re: The document's address

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 UTC