606889 - provide user control over URI mangling, which Firefox performs prior to requesting some resources

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[marginal]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100202 Ant.com Toolbar 2.0.1 Shiretoko/3.5.7
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100202 Ant.com Toolbar 2.0.1 Shiretoko/3.5.7

Since some change in the bahaviour of Firefox with version about 3 or 3.5, Firefox now makes unrequested alterations to the URI before loading it, whether from a link embedded in HTML web page, or from user entry of text into the Location Bar.

In some cases this alteration may be problematic, and so if the software is to behave in this way, the user should have an obvious and easy-to-understand option to override the change that Firefox has proposed to make to the URI prior to requesting a resource from a network server or local OS.

This function could be provided using the mechanism proposed in a related bug report filed recently, by making the proposed display field editable. See

* https://bugzilla.mozilla.org/show_bug.cgi?id=606800

Alternatively, the 'mangling' behaviour might be made optional, and the default option should be to NOT mangle anything that can be requested without mangling.

Where mangling is performed and made optional, the option to enable mangling should be grouped appropriately with other similar functions, eg if the purpose of the mangling is to prevent phishing, this should be able to be switched on and off through dialogues related to security, phishing etc. If the purpose is language encoding 'enhancements', then the option should be grouped there. 

This might mean several distinct switches for different mangling tranliterations, if so it would be useful to ALSO group the mangling switch options together somewhere as well.

Reproducible: Always

Steps to Reproduce:
1. Type text A into the location bar, but don't hit enter yet:
<http://www.xhaus.com/headers/test's fail>
2. Copy text B from the location bar and paste into a plain-text text editor.
3. Go back to the location bar, and hit enter so that the site is visited.
4. Note text C displayed in the "Requested URI" field of the page.
5. Note text D displayed visually in the Location Bar.
5. Copy text E from the location bar, and paste into your text editor.
Actual Results:  
text A: http://www.xhaus.com/headers/test's fail
text B: http://www.xhaus.com/headers/test's fail
text C: /headers/test%27s%20fail
text D: http://www.xhaus.com/headers/test's fail
text E: http://www.xhaus.com/headers/test%27s%20fail

In some cases, the refusal of Firefox to request what the user is trying to request means that web sites are incompatible with Firefox and data may not be accessed using it. In some cases, no alternative browser is available, and this means a complete loss of function wrt certain resources.

Expected Results:  
Prior to mangling of resource identification string, user should be given a hint that the literal string provided is not going to be used literally. This should occur whether the string is obtained from the Location Bar, or from an embedded HTML link, or other source, eg passed from other application software.

User should have an opportunity to amend the proposed mangling, or to defeat it and load the resource using the literal string requested.

User should have control of default behaviour in all cases.

Default behaviour should conservatively follow internet standards, as well as usage precedent set by this browser and other browsers.

Default option state for this behaviour should be 'conservative' in the sense that Firefox should attempt to alter a user's request as little as possible, rather than the current attempt to alter as much as Firefox can get away with.

The following bugreports may be useful for obtaining a sense of the complex implications of the current behaviour.

* https://bugzilla.mozilla.org/show_bug.cgi?id=84032 
* https://bugzilla.mozilla.org/show_bug.cgi?id=412458 
* https://bugzilla.mozilla.org/show_bug.cgi?id=407974 
* https://bugzilla.mozilla.org/show_bug.cgi?id=408890 
* https://bugzilla.mozilla.org/show_bug.cgi?id=124042 
* https://bugzilla.mozilla.org/show_bug.cgi?id=494877
* https://bugzilla.mozilla.org/show_bug.cgi?id=434211
* https://bugzilla.mozilla.org/show_bug.cgi?id=407172
* https://bugzilla.mozilla.org/show_bug.cgi?id=575061
* https://bugzilla.mozilla.org/show_bug.cgi?id=596840

Comment 1

[marginal]

Note: xhaus.com mentioned above is a site I found through a search engine,
which happens to provide a useful test function which enables demonstrating
this problem. I have no affiliation whatsoever. The same function of revealing
the actual content of the request header transmitted by Firefox can be
improvised without much effort, using any web server which you have
adminstrator capability over, or using the Firebug debugging plugin for
Firefox.

Comment 2

[marginal]

I have filed an additional, associated bugreport, see

* https://bugzilla.mozilla.org/show_bug.cgi?id=606929

Comment 3

[Virginia (please send need info request to Brindusa Tot)]

This seems too technical for me to try to reproduce, and the reporter is inactive so we can't ask them to provide more information. For this reason I'll be closing this ticket as Resolved - WFM.

Regards,