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