Re: URI handling for Location

Sorry, I read that too quickly.

Regarding relative URIs -- changing their syntax to allow relative  
URIs would be a breaking change for existing implementations, so at  
first blush it's out of scope for HTTPbis (and indeed anything but  
HTTP/2.0). What's the nature of the problems you're seeing with it  
being an absolute URI?

Regarding the range of content in the Location header itself -- hm.  
The majority of Location headers are produced by HTTP implementations  
themselves (e.g., from /foo to /foo/), and if they're broken, I don't  
think there's going to be a lot of sympathy for working around these  
issues.

OTOH some Location headers are going to be generated by scripts, etc.  
However, the variation in these would likely be wide, unless UAs (not  
just browsers) already implement a predictable, well-known set of  
canonicalisations.  Do they -- for Location?

Also, how widespread is this problem; are we talking about a few  
sites, or most of the Web?

I'm happy to open an issue on this second aspect, but we need more  
information than a pointer to an IRC discussion that mentions two URIs  
that produce bad Location headers. Can you give us more context, please?


On 07/04/2009, at 7:16 PM, Anne van Kesteren wrote:

> On Tue, 07 Apr 2009 06:18:18 +0200, Mark Nottingham <mnot@mnot.net>  
> wrote:
>> As discussed at the bar bof/informal liaison in SF, this seems to  
>> be more of a URI issue; i.e., HTML and browser vendors need a named  
>> construct ("dirty URI", "hypertext reference", etc.) for what goes  
>> into the process, but from an HTTP perspective, this isn't evident.
>>
>> AIUI the follow-up will happen on the URI mailing list.
>
> Allowing relative URIs hardly seems a "dirty URI" issue. As for the  
> actual "dirty URI" issue, that isn't solved as long as HTTP keeps  
> insisting the header takes an actual URI rather than such a "dirty  
> URI".
>
>
> -- 
> Anne van Kesteren
> http://annevankesteren.nl/


--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 8 April 2009 11:01:53 UTC