W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2005

Re: location uri, ucs and the http scheme definition.

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 08 Aug 2005 09:20:24 +0200
Message-ID: <42F707B8.2040902@gmx.de>
To: Robert Collins <robertc@robertcollins.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>

Robert Collins wrote:
> On Thu, 2005-08-04 at 12:19 +0200, Julian Reschke wrote:
>>Robert Collins wrote:
>>>So: what is the correct encoding approach for non US-ASCII characters in
>>>HTTP URI's in Location: ?
>>What does this have to do with "Location"? A URI never ever contains 
>>non-ASCII characters, no matter where it appears.
> Uhm. URIs do contain non-ASCII characters quite commonly. Such as
> http://example.com/~usÚrname

No, by definition that is not a URI. Non-ASCII characters are not 
allowed in URIs, that's why you need to escape them.

> Note that that cannot be unambiguously percent escaped from the rules
> contained in rfc2616 and std66. The missing link is the encoding to use
> before percent escaping, which you suggest a heuristic ..

Yes. Many servers use UTF-8, but in general a client cannot assume this 
is the case.

>>That being said; the *best* way (if you control the server) to embed non 
>>ASCII data into a URI usually is to UTF-8 encode, then percent-escape.
> What I'm asking for is current RFC or std document that specifies this.
> The reference for Location is because Location is the header I currently
> need to ensure correct encoding of, and its definition is 'absoluteURI'
> in rfc2616, which is incorporated from ... and thus we trace through to

The rules for the URI in the Location header are exactly the same as for 
the HTTP request itself, so I'm still not sure where there would be a 

> std66 which passes the buck for the canonical pre-percent-escape
> encoding back to the standard defining the URI scheme, which is rfc2616.
> Full circle and no stance taken.

There's no single encoding that will work for any server. There may be 
RFCs that recommend UTF-8 (possibly RFC3987), but these do not 
normatively effect RFC2616-compliant servers.

Best regards, Julian
Received on Monday, 8 August 2005 07:20:35 UTC

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