479145 - Some URL Encoded chars, like %7B %7C and %7D get transformed in the the browser location bar to their symbols ("|", "{" and "}"), even though these are invalid

Status: RESOLVED INACTIVE

(Firefox :: Address Bar, defect)

Description

[Luiz-Otavio Zorzella]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.04 (hardy) Firefox/3.0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.04 (hardy) Firefox/3.0.5

Typing the following URL in the location bar:

http://www.google.com/search?source=ig&hl=en&rlz=&=&q=%7B%7C%7D&btnG=Google+Search&aq=f

causes Firefox to transform it to:

http://www.google.com/search?source=ig&hl=en&rlz=&=&q={|}&btnG=Google+Search&aq=f

That happens even though these chars are not legal for the URL according to the RFC 1738:

*********

Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
   reserved characters used for their reserved purposes may be used
   unencoded within a URL.

*********

Interestingly, the server correctly gets the URL encoded characters (%7B etc). What's more, reloading the page with "Ctrl-R" will still correctly send the URL encoded chars to the server. But putting the cursor in the location bar and hitting enter (or, likewise, copying and pasting the URL to a different tab) will cause the server receive the symbols (like {|}) instead. In this experiment one can't quite tell the difference, since Google's search "survives" the illegal chars being sent, but an HTTP query inspector will show the difference.

Reproducible: Always

Comment 1

[sam]

I would add that the ampersand sign is concerned as well :

the following

http://www.site.ext/page.php?string=a+b+%26+c+d

becomes

http://www.site.ext/page.php?string=a b & c d

Furthermore in my tests (with empty cache) the server never receive the %26 or +, it always comes to it as & or ' ' (with all the problems that implies). All test on other browsers where successfull.


versions : Mac os x 10.5.7 with FF = Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10

Comment 4

[David Balažic]

1.) Still here. (v 18.0.2)

2.) Also other chars are affected, like space (see first comment in bug 552661 what chars are allowed).

3.) bug 504310 is not a duplicate of this.

4.) The entire functionality is wrong altogether. The actual URL should be shown without any "beautifying". That has led to security issues in the past, remember?

5.) Same goes for the displayed URL in the status bar when hovering over links, although that it is slightly different.

Comment 5

[ralf tauscher]

since firefox 41 this happens again.
its repro for %7B %7C and %7D   which is {|}
and still invalid as part of an URL

its related to
https://bugzilla.mozilla.org/show_bug.cgi?id=1093611

Comment 6

[4711wolke]

this might break existing web apps relying on the previous behaviour regarding browser history client implementation as it is done e. g. in the GWT framework 2.6.1 and lower

Comment 7

[kearnel]

(In reply to 4711wolke from comment #6)
> this might break existing web apps relying on the previous behaviour
> regarding browser history client implementation as it is done e. g. in the
> GWT framework 2.6.1 and lower

We are using GWT 2.5 and seems affected already (spaces and plus sign(+) in URL are not handled correctly so part of our pages are broken). Not sure how it's affected but our pages still work with Chrome and FF 38.

Comment 8

[DxP]

This is reproducible in Oracle Business Intelligence application OBIEE 11g version where Mozilla is looking for :

?catalog#{"location"%3A"%2Fshared%2FAgents"}
while Chrome / IE looks for : 
catalog#%7B%22location%22%3A%22%2Fshared%2FAgents%22%7D

And in Chrome / IE application is working fine. Major part of our application has customer Browser version dependency and they used Mozilla globally .

This happens in Mozilla latest update to 41.x but not there is FF 38 or old.
When can this be Fixed ??
thanks

Comment 9

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.