- From: Brian Smith <brian@briansmith.org>
- Date: Wed, 7 Oct 2009 14:43:37 -0500
- To: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Julian Reschke wrote: > Bjoern Hoehrmann wrote: > > In the past I've found that simply choking on relative Location > > headers is not really an option for non-browser applications, so I > > do think the specification should say something about them, even if > > that's just a note to the effect that implementers are likely to > > encounter them. > > Relative ___location headers per se aren't a problem; those that also > include a fragment id are. You only checked a very small number of clients. That isn't sufficient to make such a big, incompatible, change to the syntax. It is a good idea to warn client implementers about relative links and/or fragment ids in the Location header. However, it is a bad idea to allow servers to send them. It should be handled instead like obsolete syntax. Proposal: ------------- 9.4. Location The response-header field "Location" is used for the identification of a new resource or to redirect the recipient to a ___location other than the request-target for completion of the request. For 201 (Created) responses, the Location is that 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 absolute URI. Location = "Location" ":" OWS Location-v - Location-v = absolute-URI [ "#" fragment ] + Location-v = absolute-URI An example is: Location: http://www.example.org/pub/WWW/People.html + The Location header field value MUST be an absolute-URI; + In particular, it MUST NOT be a relative-ref and it + MUST NOT have a fragment. + For compatibility with erroneous servers, if the + Location header field value is a relative-ref (with or + without a fragment), a client MAY resolve it relative to + the request target. + 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. - - There are circumstances in which a fragment identifier in a Location - URL would not be appropriate: - - o With a 201 Created response, because in this usage the Location - header specifies the URL for the entire created resource. - - o With a 300 Multiple Choices, since the choice decision is intended - to be made on resource characteristics and not fragment - characteristics. - - o With 305 Use Proxy. Regards, Brian
Received on Wednesday, 7 October 2009 19:44:08 UTC