User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:184.108.40.206) Gecko/2008102920 Firefox/3.0.4 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:220.127.116.11) Gecko/2008102920 Firefox/3.0.4 If you try to navigate to http://google.com:%38%30/, Firefox will normalize and navigate to http://google.com:38/ instead, which is clearly wrong. Reproducible: Always Steps to Reproduce: 1. Navigate to http://google.com:%38%30/ Actual Results: Firefox tries to connect to port 38 on google.com. Expected Results: Firefox should have tried to connect to port 80 on google.com. Opera and IE both normalize to http://google.com/ which seems reasonable to me since "%38%30" unencodes to "80". Safari gives a weird error message.
From reading RFC 3986, it's pretty clear that percent encoding port numbers is not legitimate. However, pulling out a numeric valid from a percent encoded string is even less legitimate. The way I see it, there's only two sensible approaches here. You could take the purist approach and give an error message. Or you could take the liberalist approach and unencode the port component before looking for a numeric value.
Dao: Something with how firefox decodes uris? Might be more than just firefox though.. If you hover over the URL link, it already shows google.com:38, so not just the location bar decoding logic..
Yeah sorry, I knew it wasn't location bar specific, but I didn't see a better place to categorize the bug.
This is fixed on trunk, still a problem in 3.6.x. Realistically we're not going to backport this fix.