- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Thu, 19 Dec 2002 16:33:47 +0100
- To: Bill de hÓra <dehora@eircom.net>
- Cc: Paul Prescod <paul@prescod.net>, Dare Obasanjo <dareo@microsoft.com>, WWW-Tag <www-tag@w3.org>
Am Donnerstag, 19.12.02, um 15:49 Uhr (Europe/Berlin) schrieb Bill de
hÓra:
> 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:
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
"
//Stefan
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