RE: Issue 43 (combining fragments)

Roy T. Fielding wrote:
> On Oct 7, 2009, at 12:56 PM, Julian Reschke wrote:
> > The change to allow fragments has been discussed, and approved long
> > before this WG has started to work. See <http://skrb.org/ietf/
> > http_errata.html#location-fragments>, which, unfortunately,
> > currently is broken because that page is truncated.
> >
> > The change request to allow non-absolute URIs is newer, but makes a
> > lot of sense to me. First of all, it's used in the wild, and it
> > appears clients accept it. Second, disallowing them simply makes no
> > sense. Forcing implementers to include redundant information
> > doesn't work well, and if the requirement is followed, sometimes
> > leads to broken information (for instance by broken reverse proxies).
> 
> I'll add that it has also been a long-standing request
> of server developers, ever since Host was introduced, to be
> able to use relative URIs in Location.  Browsers have supported
> that since 1997 or so, I think.

Agreed. But, as Julian showed, these features doesn't work together
in a sensible way in any browser. 

Servers really SHOULD use the absolute form of URI for
interoperability's sake. There's really no reason not to since
every server and every server framework has been designed to
facilitate this. But, clients SHOULD accept the relative form
too, like I said. Really it's just Postel's rule.

I don't think there's any sensible way of defining the processing
of fragment identifiers in the Location header, except to acknowledge
their use for HTML documents in web browsers, and recommend that
clients should try not to choke on them. But, it seems far from
obvious that every document type in every application should be
handled that same way. For example, what should a web crawler
do with Julian's test cases? I don't think you can say that it
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.

There really does need to be a clear warning that clients may
not implement these features, because they were not in RFC 2616.

Regards,
Brian

Received on Thursday, 8 October 2009 02:16:05 UTC