RE: Issue 43 (combining fragments)

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