1502281 - Bad history item causes Firefox to keep sending request to bad URL

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, defect)

Description

[swordangel]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

0. Start a brand new Firefox profile.
1. Try to visit http://www.k-lug.org/~kessler/projects.html
2. The server returns an HTTP 301 with a bad Location header to "http://k-lug.org~kessler/projects.html" (a slash is missing before the tilde).
3. Obviously Firefox can't find that site.
4. Open the "Network" tab of the web developer console.
5. Fix the URL in the address bar. The correct URL should be "http://k-lug.org/~kessler/projects.html" (without the "www." in front of the domain name).
6. Press enter.


Actual results:

Firefox sends a request for "http://www.k-lug.org/~kessler/projects.html" anyway, which causes the server to return HTTP 301 with a incorrect Location header again.


Expected results:

Firefox should send a request for "http://k-lug.org/~kessler/projects.html" and succeed in loading the page.

Note that if we opened a new Firefox profile and never visited the bad URL (with the "www." in the domain name), then typing "http://k-lug.org/~kessler/projects.html" into the address bar and pressing enter works as expected.

If we clear the history after visiting the bad URL, it also works expected.

If we visited the bad URL in Firefox, then click a link to the correct URL in another application (e.g. clicking a link to "http://k-lug.org/~kessler/projects.html" in HexChat), FF also loads the page as expected.

Comment 1

[swordangel]

Also note that the behaviour depends on the order of the history items: if you visited the good URL first, and then the bad URL, subsequent visits to the good URL will be ok.

Comment 2

[laszlo.bialis]

Hi,

I've managed to reproduce the issue above on the latest Nightly 65.0a1 20181123100103, both on Ubuntu 16.04 as on Win10 x64.

I am assigning a component to this issue in order to involve the development team and get an opinion on this.

Comment 3

[Marco Bonardo [:mak]]

Initially you tried to go to the www. version, that returned a non permanent error from the server, so the url was considered valid. When you type the non www version without specifying http://, we add www. because history knows about that url you initially typed and supposes you want to go there. If you'd also type http:// (or https) we'd not add www.
Visiting even just a few times the correct page will correct autofill to not add www.

Here we can't do much, each of the choices (adding www or not) would have consequences on the opposite case (you don't type www but the site only replies to the www. version), so for now we'll stick to frecency and adaptation.