- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 10 Mar 2010 14:06:26 +0100
- To: HTTP Working Group <ietf-http-wg@w3.org>, "public-html@w3.org" <public-html@w3.org>
Hi, the HTTPbis WG has two open tickets with respect to the syntax and semantics of the Location header (not to be confused with Content-Location!): a) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment combination / precedence during redirects" This is about how to handle the case when both the original URI and the value of the Location header contain a fragment identifier. b) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location header payload handling" This is about allowing relative references (in addition to full URIs), and also about treating broken values (*). Some time ago I created a few tests, see <http://greenbytes.de/tech/tc2231/redirects.html>. What I found was that - UAs appear to treat those consistently (with the exception of Opera, but Yngwe already signaled that he's willing to adapt), *but* - the behavior I found unfortunately doesn't make sense (treating the cases for absolute URIs and relative references differently). Specifically, I would expect UAs to let the fragment ID found in the Location header (when present) override the original URI's. But we found this to be only the case for absolute URIs. At this point, and with no further feedback from browser vendors about whether they'd consider changing the behavior for relative references, we changed the spec to clarify that the fragment recombination behavior is undefined (previously, the spec didn't say anything about this). The new text for "Location" is: -- snip -- 9.4. Location The "Location" response-header field is used to identify a newly created resource, or to redirect the recipient to a different location for completion of the request. For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single URI-reference. When it has the form of a relative reference ([RFC3986], Section 4.2), the final value is computed by resolving it against the effective request URI ([RFC3986], Section 5). Location = "Location" ":" OWS Location-v Location-v = URI-reference Examples are: Location: http://www.example.org/pub/WWW/People.html#tim Location: /index.html There are circumstances in which a fragment identifier in a Location URI would not be appropriate: o With a 201 Created response, because in this usage the Location header specifies the URI for the entire created resource. o With 305 Use Proxy. Note: This specification does not define precedence rules for the case where the original URI, as navigated to be the user agent, and the Location header field value both contain fragment identifiers. Note: The Content-Location header field (Section 5.7 of [Part3]) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the response. It is therefore possible for a response to contain header fields for both Location and Content-Location. -- snip -- (see also <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#header.location>). Of course it would be nice if we *could* recommend a specific behavior that makes sense, so I would be very grateful to get feedback from UA implementers about whether they'd consider treating relative references and absolute URIs consistently. Best regards, Julian (*) We'll look at *that* issue separately. On 10.03.2010 13:19, Julian Reschke wrote: > On 09.03.2010 17:54, Julian Reschke wrote: >> ... >> OK, here's a proposal >> (<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/43/i43.diff>): >> >> >> >> - allow relative references >> >> - state that we do not specify fragment recombination >> >> - stay silent on invalid URI-references (I think we should discuss this >> as an orthogonal issue). >> >> The changed text for the Location header would be: >> ... > > Applied with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/785>. > > I'll send a separate summary, and cc' the W3C HTML WG, trying (yet > again) to get feedback from browser vendors about whether they're > willing to go further than that. > > Best regards, Julian >
Received on Wednesday, 10 March 2010 13:07:09 UTC