Are URIs case-insensitive?

Question 1

In reality it depends on the web server.

IIS is not case sensitive.

Apache is.

I suspect that the decision regarding IIS is rooted in the fact that the Windows file system is not case sensitive.

IIS still meets that portion of the spec because SHOULD is a recommendation, not a requirement.

Question 2

the scheme and host are case-insensitive and therefore should be normalized to lowercase. For example, the URI <HTTP://www.EXAMPLE.com/> is equivalent to <http://www.example.com/>. The other generic syntax components are assumed to be case-sensitive unless specifically defined otherwise by the scheme

RFC 2616 defines the following comparison rule for the HTTP scheme:

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:

However, RFC 7230 locks it down further by stating:

The scheme and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner.

Those rules typically apply to client side comparisons. There are no rules specifically geared for server side comparisons. Once a server breaks up a URI into its components, it should treat them according to the same rules, but I don't see that enforced in the RFCs. Some web servers, like Apache, do follow the rules. IIS doesn't, for compatibility with Windows' case-insensitive file system.

Question 3

The host portion of the URI is not case sensitive:

http://stackoverflow.com
http://StackOverflow.com

Either of the above will get you to this site.

The rest of the URI after the host portion can be case sensitive. It depends on the server.

Question 4

As mentioned in answer by Remy Lebeau, the rules are set for client side. Actually, this means that client software should not try to make arbitrary case modifications to all parts of URIs, except for specifically stated parts. So, when a browser e.g. sees a relative URL in a page anchor, is should not convert it to lowercase before checking if it is already cached in its cache; neither should it use the URI lowercased to post to server. Also, it should not decide that two URIs that differ in case only point to same resource (thus possibly wrongly skipping a transaction and returning cached result instead).

This means that client should not assume how servers treat the URIs. It does require servers to treat some parts case-insensitive: e.g., scheme and host. But otherwise, it's up to server to decide if two URIs that differ in case point to the same resource, or not. Standard does not impose any restrictions on servers in this regards, there's nothing "server should" or "server should not" besides directly prescribed. If server decides that its URIs are case-insensitive, that's absolutely fine. If they are case-sensitive, that's fine, too.

Question 5

Whether or not URLs are treated as case-sensitive also depends on the web server. For example, Microsoft IIS servers do not treat URLs as case-sensitive.

The following URLs (hosted on a Microsoft IIS server) are both treated as equivalent:

However, Apache servers do treat URLs as case-sensitive are classed as two different resources:

Technically, Apache is following the standards correctly here, and Microsoft is going against the specification… Oh well – “old habits die hard,” they say!

Question 6

For a file-based URI, case-sensitivity depends more on the underlying file system, not so much the web server. Apache will happily return index.html for INDEX.html on Windows (FAT, NTFS) and mac (HFS), but not for case-sensitive file systems such as those usually used in Linux (extx and so forth).