Re: The document's address
Nicholas Shanks <[email protected]> Fri, 18 Jan 2013 11:46:58 +0000
| Newsgroups | gmane.ietf.http-wg,gmane.comp.web.html.general |
|---|---|
| Message-ID | <CA+hEJVXz61Z16v5scW=YnM_5f6MY==PBySor82hRFA+rbuDuZw@mail.gmail.com> |
On 17 January 2013 19:49, Ian Hickson <[email protected]> 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.