Re: Issue 43 (combining fragments)

On Oct 7, 2009, at 12:56 PM, Julian Reschke wrote:

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

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.

....Roy