- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Fri, 18 Jan 2013 04:23:21 -0800
- To: Nicholas Shanks <nickshanks@gmail.com>
- 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>
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:45 UTC