- 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