W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

RE: Issue 43 (combining fragments)

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>
Message-ID: <001e01ca4816$60933160$21b99420$@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

  * 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.

Received on Thursday, 8 October 2009 12:54:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:52 UTC