Open Bug 536955 Opened 10 years ago Updated 5 years ago

Firefox location bar search broken using proxy


(Core :: DOM: Navigation, defect)

Not set




(Reporter: pichlik, Unassigned)




User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv: Gecko/20091201 Firefox/3.5.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv: Gecko/20091201 Firefox/3.5.6

The problem occur when searching for a *single word* using the location bar and the proxy settings are "Manual proxy configuration". Firefox doesn't perform a fulltext search, but redirects directly to http://<entered word>. 

Reproducible: Always

Steps to Reproduce:
1. Install a proxy server e.g. to localhost:8080
2. Change Firefox proxy settings to Manual proxy configuration and enter HTTP proxy: localhost and port:8080
3. Enter a single word into the location bar and hit enter
Actual Results:  
Firefox doesn't perform a fulltext search, but redirects directly to http://<entered word>.

Expected Results:  
Fulltext search for entered word.

When multiple words is entered search works fine. The exactly same problem has been descibed here
Version: unspecified → 3.6 Branch
Summary: Firefox location bar search broken using proxy → Firefox location bar fulltext search broken using proxy
Summary: Firefox location bar fulltext search broken using proxy → Firefox location bar search broken using proxy
Confirmed as recently as 8.0beta3 and 7.0.1 release. Fully reproducible with the steps mentioned above.

Tested in Windows XP, but as far as I know, this is architecture independent, and has to do with the way Firefox works when you use a single word in the URL bar, i.e.: word

- Firefox will try to download it the http://word URL: 

GET / HTTP/1.1
Host: word

- if it doesn't work (e.g. it won't resolve to a local hostname or an IP address), it will result in a search.

Problem: when there's a proxy, the proxy answers the query with an error page. Instead of the 504 error page (gateway timeout), it uses a 403 error (forbidden). Since that is a final error, Firefox no longer tries, and search is never invoked.

e.g. full interchange (with nonrelevant headers edited out)

GET http://word/ HTTP/1.1
Host: word
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
DNT: 1
Proxy-Connection: keep-alive
Cache-Control: max-age=0

HTTP/1.1 403 Forbidden
Content-Length: 456
<html><head><title>504 DNS look up failed</title></head><body><font size=2><table width="100%"><tr><td bgcolor=#3300cc align="center" colspan=2><font color=#ffffff><b>504 DNS look up failed</b></font></td></tr></table><br><br>The webserver for http://word reported that an error occurred while trying to access the website.  Please click <u><a href="javascript:history.back()">here</a></u> to return to the previous page.<br><br><hr></font></body></html>

i.e. even if the proxy's error page says it's a 504 error, the actual error code returned is 403 ("Forbidden"), so Firefox does the right thing and doesn't do anything else.

It's the proxy's fault, but it's still very annoying and I wonder if there could be a way for Firefox to handle this more gracefully.
(In reply to Shane Killian from comment #5)
> Still occurring with Firefox 22.0. Anyone?

Yes and pretty annoying.

Android -> Firefox 22 -> Proxy Mobile 0.0.10 (FF Add-on) -> Tor-Proxy (Orbot App)
Duplicate of this bug: 625360
Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0

Reproducible with latest Nightly (Build ID: 20130811030225) when using a proxy server.

Here is what I get in the error console:

Request URL: 	http://test/
Request Method:	GET
Status Code: 	HTTP/1.1 403 Forbidden
Request Headers 
User-Agent:	Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0
Host:	        test
Connection:	keep-alive
Accept-Encoding:gzip, deflate
Accept:	        text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Temporary workaround: if you put the single word in quotes, it does the search instead of asking the proxy.
Duplicate of this bug: 861509
As dolske said, the fix should be located in particularly the stuff involved with ALLOW_THIRD_PARTY_FIXUP in it. dolske took a dab at it here :
Flags: firefox-backlog?
Component: Location Bar → Document Navigation
Flags: firefox-backlog? → firefox-backlog-
Product: Firefox → Core
Version: 3.6 Branch → unspecified
Thanks for the link, Saurabh, but I don't think it would fix this particular issue as the user isn't brought to a Firefox error page, but one created by the proxy server. To fix this bug, the browser must know in advance that it isn't a proper URL (i.e., doesn't end in ".com" or any other TLD, etc.) and that it should go ahead and send it to the default search engine instead of the proxy server, just the way it does with multi-word searches.

The problem seems to be that Firefox is just assuming that any single word typed into the Address Bar is a URL to be sent to the proxy, instead of checking it first.
This might be a non bug. Certain proxies add domains (including new TLDs) for "internal" URLs, so the location bar shouldn't be interfering. Since the proxy is returning an error page with content (and possibly with the wrong error code), Firefox can't simply hide the error page and move on to search.
In my case, but the problem may be different.
On Windows 7 64 bits French.
With proxy.
Open Firefox.
When enter one word in the search bar.
Search is doing, you can see this on the tab. No results appear. And the windows for login/password for proxy didn't appear.
Saw this problem many times with Firefox 28.0, but haven't seen yet with the newest version.

This problem can be solved temporarily by deleting the Firefox directory in C:\Users\xxx\AppData\local\, maybe the cache directory. Deleting cache with the Firefox menu is not enough.
About comment 18. I wrote it.
Mmmh, seems this not the same problem, because the problem problem discribed in comment 18 doesn't affect Firefox 5, 9, 10, 18.

Sorry for the inconvenience.
You need to log in before you can comment on or make changes to this bug.