User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release) Build ID: 2014072000 Steps to reproduce: Visit any URL with upper-case letter(s) in domain name, for example: ABC.example.com Hitting enter, and Firefox turns all upper case letters into lower case letters in the domain portion. Being unfamiliar with URL-related RFC standards, I am not sure whether this is a desired behaviour or not. Actual results: ABC.example.com navigates to abc.example.com Expected results: ABC.example.com navigates to ABC.example.com
Probably invalid bug because abc.example.com can be reached by entering ABC.example.com.
Component: General → Networking
Thanks Loic. I noticed the bug when I was trying to access a web application deployed behind AWS Load Balancer. The deployed application is served by Apache HTTP server with a buggy URL-rewrite rule, the rule rewrites an Amazon load balancer URL such as "TestELB.eu-west-1.elb.amazonaws.com/mypath" into "/anotherpath". The URL-rewriter is at fault because the rule should have matched domain name in a case-insensitive way. However, putting it aside, I was unable to use the site at all because Firefox turns the domain name into lower case: "testelb.eu-west-1.elb.amazonaws.com/mypath".
The rewrite rule is presumably relying on the Host header, right? The relevant RFC is DNS, which says that domain labels is case insensitive. So in the spirit of Postel's law, browsers always use lowercase DNS labels... That said, I see nothing to this effect in http://url.spec.whatwg.org/
Thanks Boris. You are right. Firefox makes the domain name lower-case on the user interface, and also sends the Host Header in lower case. I agree with you that Firefox is doing the right thing, since multiple sources suggest that domain names should be case insensitive. Therefore I'd like to get Firefox team's feedback on whether to make this an issue, or just "working as expected".
The way this works in the URL Standard is that you end up invoking the host parser http://url.spec.whatwg.org/#concept-host-parser which ends up invoking http://url.spec.whatwg.org/#concept-domain-to-ascii if the input is not IPv6. That in turn runs http://www.unicode.org/reports/tr46/#ToASCII with various variables set. That in turn runs http://www.unicode.org/reports/tr46/#Processing which as step 1 uses a mapping table that is responsible for lowercasing these code points. This is somewhat convoluted, but once you start dealing with Unicode things just kind of are that way.
Ah, thanks. Just wanted to make sure this was in fact specced. Sounds like things are all good here in the sense of all the browsers matching each other and the spec.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.