I was reading the W3C URL Specification and I noticed that there is nothing explicitly mentioned about this.
Experiments
So what I tried in curl was
www.google.com
and then
www.GOOGLE.com
and these returned the same document. So I thought maybe google owns all variations on its domain name, so I tried other sites and I get mixed results.
So I mixed the case on the URL Specification and it seems to allow mixed case.
Applying this to REST API Design
So when applying this to REST API design, sometimes we use the notion of an identifier to return a specific resource from the server. E.g.
In https://localhost:8080/contacts/MYSELF, MYSELF would be the typical identifier
Based on those previous experiences, the case of MYSELF should not matter. But what if I wanted strict validation on the identifier?
Sure, you can go against the spec and do this in the application; but what is the appropriate thing to do in this case?
So back to the subject. Are URLs meant to be case insensitive?
In the general URI syntax (as defined by RFC 3986, which is currently the Internet Standard for URIs), only two components are case-insensitive:
And the letters in percent-encoding triplets (i.e., a-f, A-F) are case-insensitive, too.
Everything else is case-sensitive.
However, URI schemes can overwrite this for their URIs (see Case Normalization).
In the case of HTTP(S) URIs, the spec doesn’t make any other components case-insensitive (it restates that scheme and host are case-insensitive).
That means the following HTTP URIs are equivalent:
http://example.com/foo
HTTP://example.com/foo
http://EXAMPLE.com/foo
http://example.COM/foo
HTTP://EXAMPLE.COM/foo
htTp://exAMPlE.cOm/foo
(Best practice is to normalize scheme and host to lowercase.)
And these are not equivalent:
http://example.com/foo?bar#baz
http://example.com/fOo?bar#baz
http://example.com/foo?bAr#baz
http://example.com/foo?bar#bAz
http://example.com/FOO?BAR#BAZ