410429 - Location bar incorrectly decodes entered URLs

Status: RESOLVED DUPLICATE of bug 397815

(Firefox :: Address Bar, defect)

Description

[Alex Sirota (iosart)]

In Firefox 3b2 URLs entered into the location bar are incorrectly url decoded.

Example:
1. Enter URL into location bar: 'http://localhost/hello%252fworld'
2. The URL is automatically changed into 'http://localhost/hello%2fworld' and that URL is loaded instead of the correct original one

Comment 1

[Jo Hermans]

%25 is the hexadecimal code for %, so I think that Firefox is doing what it's asked to do. If you want to load a URL called hello%252fworld (like a file with that name), then the URL is <http://localhost/hello%25252fworld>

Comment 2

[Jo Hermans]

Can you mention a reason why a URL should not be decoded ? If FF didn't do this, then you can't acces URL with a / in the name, for instance, because it would be mistaken for the separator.

Comment 3

[Alex Sirota (iosart)]

A couple of comments:
1. As far as I understand, the location bar should only change non-url-valid characters entered, to their URL encoded equivalents. The sequence %252f is already a valid URL sequence and so I believe it should not be encoded nor decoded when entered
2. The new behavior of transforming '%252f' to '%2f' is inconsistent with previous versions of Firefox and other browsers (tested with IE7), which behave correctly
3. When URLs such as 'http://localhost/hello%252fworld' are opened programatically, the correct URL (with %252f) is sent to the server and the correct page is returned, but the URL displays the incorrectly decoded URL (http://localhost/hello%2fworld). Hitting 'reload' in this window would now send the second (wrong) URL to the server, which would produce different results! Beyond being confusing, this might potentially have security implications, because URL displayed in the address bar is different from what was actually sent to the server.
4. In web applications that expect a double encoded '/' (= %252f) - there is now no way to enter this url into the address bar. Also, working with such applications, reloading pages and/or cutting/pasting URLs into new windows will produce unexpected results - see (3) above 

Comment 4

[Jo Hermans]

I think it was changed due to the IDN changes. There's some pretty-printing being applied to get rid of puny-code and such. And also to clean URL's with various other encoded characters.

Your point 3 seems to be a bug. The reload should obviously sent the same data every time.

Comment 5

[Alex Sirota (iosart)]

I believe that my point 1 above is also a bug, and IMHO a serious one.

Here's a couple of real life scenarios in which this will break existing web apps:
1. By default Apache doesn't allow slashes (%2F) in URLs, and returns 404 when it sees such URLs - http://httpd.apache.org/docs/2.0/mod/core.html#allowencodedslashes
Many applications solve this by double encoding the URL to have %252F instead of %2F. With the new behavior, entering (or cutting and pasting) such legal URLs into the address bar will immediately transform all %252F to %2F, and hitting 'enter' will launch the request and return 404! This is the first bug. The second bug, which is the result of the first one is that (as I mentioned above), opening such URLs programatically will send the correct URL to Apache, but display the wrong URL in the address bar. So, the user will see the correct returned page, but hitting reload or pasting such URL into another window will result in 404. 
2. Many referral/affiliate sites and programs work as follows - instead of referring users to the direct URL of an affiliate, you send them to an intermediate site with the original URL as a parameter. This intermediate site records the transaction and redirects to the final URL. In this scenario, the original URL param is often double URL encoded with %252F being used for slashes. This bug would potentially break many things related to any such scenario.

blocking‑firefox3?