W3C home > Mailing lists > Public > www-tag@w3.org > December 2002

Re: uri-comp draft necessary?

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Thu, 19 Dec 2002 16:33:47 +0100
Cc: Paul Prescod <paul@prescod.net>, Dare Obasanjo <dareo@microsoft.com>, WWW-Tag <www-tag@w3.org>
To: Bill de hÓra <dehora@eircom.net>
Message-Id: <4422FD2F-1367-11D7-BD6D-00039384827E@greenbytes.de>

Am Donnerstag, 19.12.02, um 15:49 Uhr (Europe/Berlin) schrieb Bill de 

> Stefan Eissing wrote:
>> I think Dare's point was well made:
>> For HTTP servers and proxies, http://example.com/ and 
>> HTTP://example.com/ must
>> be equivalent URIs. They have to follow RFC 2396 in that.
> I couldn't find anything in rfc2396 that says HTTP and http must be 
> treated as equivalent, it does say they should be treated as 
> equivalent, but that's a different level of specification.

Ok, its not in 2396. It's in 2616,  Ch. 3.2.3:

"URI Comparison

When comparing two URIs to decide if they match or not, a client SHOULD 
use a case-sensitive octet-by-octet comparison of the entire URIs, with 
these exceptions:

     * A port that is empty or not given is equivalent to the default 
port for that URI-reference;
     * Comparisons of host names MUST be case-insensitive;
     * Comparisons of scheme names MUST be case-insensitive;
     * An empty abs_path is equivalent to an abs_path of "/".

Characters other than those in the "reserved" and "unsafe" sets (see 
RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.

For example, the following three URIs are equivalent:



PS. Did someone note that '~' is equivalent to '%7e'? Can we rule out 
EBCDIC as charset for
     http URIs, at least? please?
Received on Thursday, 19 December 2002 10:34:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:35 UTC