- From: Brian Smith <brian@briansmith.org>
- Date: Thu, 8 Oct 2009 07:53:41 -0500
- To: "'Julian Reschke'" <julian.reschke@gmx.de>
- Cc: "'Roy T. Fielding'" <fielding@gbiv.com>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
Julian Reschke wrote:
> Brian Smith wrote:
> > MUST or SHOULD replace the fragment in original URI with the
> > Fragment in the Location header. Keep in mind that the server
> > doesn't even know what the original fragment was when it minted
> > the Location header.
>
> Well, if we add it, it would be a specification of client
> behavior, not server behavior.
What I meant is: I don't see how you can define the client behavior
Of redirects with fragments in a way that makes sense for all
clients (not just browsers). And, even in the case of browsers, I
don't see why Opera's behavior should be considered wrong. So,
even if fragments are allowed syntactically, the semantics still
will be undefined.
Every client that will conform to this specification sends a Host
header to the server. And, a relative URL in a Location header
would always be resolved relative to that Host header value.
So, the server CAN always generate a URI; it never needs to
generate a relative URI reference in the cases where it would
be allowed to do so. Accordingly, in light of your demonstration
of how poorly these two extensions work together, I think it
makes the most sense to say something like this:
* Change the syntax to:
Location-v = URI-reference
This would resolve issue #185.
* Don't say anything about the semantics of fragments in
redirects. This would close issue #43 with no change.
* Note in the "Changes from RFC 2616" that the syntax of
the Location header was changed from absolute-URI to
URI-reference in order to allow relative URI references
and fragments.
I noticed the wording of the language regarding fragments is poor:
There are circumstances in which a fragment identifier in a
Location URI would not be appropriate:
* With a 201 Created response, because in this usage the
Location header specifies the URI for the entire created
resource.
* With 305 Use Proxy.
This should be reworded to use RFC 2119 terminology. I suggest:
The Location header field value MUST NOT include a fragment
If the response status code is 201 Created or 305 Use Proxy.
Regards,
Brian
Received on Thursday, 8 October 2009 12:54:15 UTC