Is the hostname part of HTTP(S) URLs truly case-insensitive?

Nils Toedtmann asked:

Is it safe to use http(s):// as URL (e.g. for branding purposes) without any changes to the service-side configs?

I know that DNS is case-insensitive, but could there still be side-effects? I am thinking of e.g. various parts of the chain failing to match ~

  • Some web backend might fail to match
  • Some load balancer/proxy/cache/application layer firewall might fail to match
  • Some client might apply same-origin policies wrongly
  • Some client might fail to match in certificate checks
  • While DNS is generally case-insensitive, could IDNs change the picture?

Anyone experienced those or other issues with capitals in the hostname part of URLs?

@Michael Hampton pointed out that, according the the HTTP standards, the hostname IS case-insensitive, but some software is non-compliant in this regard.

I try to get a sense of how prevalent non-compliant software is, in particular clients. I assume all recent major browsers are fine, but what e.g. about mobile apps? (Should I better split this off into a separate SF question?)

My answer:

Yes, the hostname really is case-insensitive, as specified in RFC 3986 § 3.2.2, because hostnames in general are case-insensitive in the DNS. This RFC also gives recommendations on how to avoid the problems you mentioned:

Although host is case-insensitive, producers and normalizers should use lowercase for registered names and hexadecimal addresses for the sake of uniformity, while only using uppercase letters for percent-encodings.

I have seen at least one HTTP cache (W3 Total Cache) which does not normalize the hostname in this manner, and ends up caching content multiple times, e.g. under, Example.Com, EXAMPLE.COM, etc.

View the full question and answer on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.