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: Wed, 07 Oct 2009 21:56:10 +0200
Message-ID: <4ACCF25A.1020708@gmx.de>
To: Brian Smith <brian@briansmith.org>
CC: 'HTTP Working Group' <ietf-http-wg@w3.org>
Brian Smith wrote:
> Julian Reschke wrote:
>> Bjoern Hoehrmann wrote:
>>> In the past I've found that simply choking on relative Location 
>>> headers is not really an option for non-browser applications, so I 
>>> do think the specification should say something about them, even if 
>>> that's just a note to the effect that implementers are likely to 
>>> encounter them.
>> Relative location headers per se aren't a problem; those that also 
>> include a fragment id are.
> 
> You only checked a very small number of clients. That isn't sufficient to
> make such a big, incompatible, change to the syntax.
> 
> It is a good idea to warn client implementers about relative links and/or
> fragment ids in the Location header. However, it is a bad idea to allow
> servers to send them. It should be handled instead like obsolete syntax. 
> ...

Disagreed.

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

BR, Julian
Received on Wednesday, 7 October 2009 19:56:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:12 GMT