- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 7 Oct 2009 17:52:33 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Brian Smith <brian@briansmith.org>, 'HTTP Working Group' <ietf-http-wg@w3.org>
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
Received on Thursday, 8 October 2009 00:53:00 UTC