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

Re: Issue 43 (combining fragments)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 08 Oct 2009 12:19:40 +0200
Message-ID: <4ACDBCBC.1050500@gmx.de>
To: Brian Smith <brian@briansmith.org>
CC: "'Roy T. Fielding'" <fielding@gbiv.com>, 'HTTP Working Group' <ietf-http-wg@w3.org>
Brian Smith wrote:
> ...
>>> 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. 
> ...

They do, except for the case of absolute path + fragment id, which is a 
relatively new request.

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

Can you elaborate? How does it affect a web crawler in any way?

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

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

With respect to URI + fragment ID, I disagree. This has been a 
well-documented erratum for something like 10 years, and is definitely 
in use in practice.

BR, Julian
Received on Thursday, 8 October 2009 10:20:22 UTC

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