Calling virtual host (e.g. http://vhost.localhost ) automatically redirects to https://vhost.localhost
Categories
(Core :: Networking, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox84 | --- | fixed |
People
(Reporter: jmpc, Assigned: valentin, NeedInfo)
References
Details
(Whiteboard: [necko-triaged][fixed by bug 1675587])
Attachments
(2 files)
20201009 Problem loading page vs GC.png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0
Steps to reproduce:
• I installed WSL2 and run an Ubuntu 20.04 in it
• vhost.localhost is installed as another virtual host
• vhost.localhost is enabled
• C:\Windows\System32\drivers\etc\hosts has entry 127.0.0.1 vhost.localhost
• /etc/hosts entry is added via automatic process (and works fine)
• Calling the website using CURL works fine
Actual results:
Trying to open http://vhost.localhost it automatically switches to https://vhost.localhost and then this site cannot be loaded.
Expected results:
It should be able to display the virtual hosts to, even when hosted in WSL2.
|
Reporter | |
Comment 1•4 years ago
|
||
With this screenshot I try to give a better overview of the topic and to prove, that (at least I really, really hope so) I have not configured anything wrong in this case. And last I also try to prove, that it works with Chrome while it does not with Firefox.
|
||
Comment 2•4 years ago
|
||
Setting a component for this issue in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.
|
Assignee | |
Comment 3•4 years ago
|
||
This is a weird one.
As far as I can tell, loading http://vhost.localhost as described in comment 0 should not work.
If I try to do wget http://vhost.localhost it fails saying port 80 is not open.
The reason Chrome seems to work is that is that it tries to load [::1]:80 - even though that IP is not returned by /etc/hosts
I think this might start working once Bug 1220810 lands - but it's very odd behaviour as far as I can say.
|
|
Assignee | |
Comment 4•4 years ago
|
||
Note - the upgrade to https happens because loading http://vhost.localhost fails.
|
||
Comment 5•4 years ago
|
||
(In reply to Valentin Gosu [:valentin] (he/him) from comment #4)
Note - the upgrade to https happens because loading
http://vhost.localhostfails.
Right, this is what was implemented in bug 1002724
Actually the remaining failing test before being able to land the patch for bug 1220810 is
https://searchfox.org/mozilla-central/source/docshell/test/browser/browser_fall_back_to_https.js
which expects a similar redirect from "http://127.0.0.2" to "https://127.0.0.2" ; do we really want to keep that behavior?
|
|
Assignee | |
Comment 6•4 years ago
|
||
(In reply to Frédéric Wang (:fredw) from comment #5)
(In reply to Valentin Gosu [:valentin] (he/him) from comment #4)
Note - the upgrade to https happens because loading
http://vhost.localhostfails.Right, this is what was implemented in bug 1002724
Actually the remaining failing test before being able to land the patch for bug 1220810 is
https://searchfox.org/mozilla-central/source/docshell/test/browser/browser_fall_back_to_https.js
which expects a similar redirect from "http://127.0.0.2" to "https://127.0.0.2" ; do we really want to keep that behavior?
I'm not sure about that. Christoph?
|
||
Comment 7•4 years ago
|
||
(In reply to Valentin Gosu [:valentin] (he/him) from comment #6)
which expects a similar redirect from "http://127.0.0.2" to "https://127.0.0.2" ; do we really want to keep that behavior?
I'm not sure about that. Christoph?
I am not 100% certain myself. Probably we don't want that behavior in the end and it's better to update /browser_fall_back_to_https.js to do something else for automated testing of the https: fallback.
|
|
Reporter | |
Comment 8•4 years ago
|
||
@Valentin Gosu, should I attach the settings of my apache server too? It has an entry for vhost.localhost but I can also give more detailed information if required. But as far as I found out you can use any configuration of a virtual host in combination with localhost and it's not working.
|
|
Assignee | |
Comment 9•4 years ago
|
||
No need. I made the same setup on my local machine.
The reason it works in Chrome is that it also attempts to load [::1]:80 after 127.0.0.1:80 fails.
Firefox doesn't do that since there is no IPv6 entry in /etc/hosts - but it might start working once Bug 1220810 lands - since we'll synthetically generate localhost IP entries.
That said, I'm not sure this should work. As I mentioned above, using wget http://vhost.localhost also fails.
If the WSL2 setup would make routing IPv4 addresses work a little better, maybe by using a different IP for the virtual hosts, I think it would make this scenario a little nicer.
|
|
||
Comment 10•4 years ago
|
||
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #7)
(In reply to Valentin Gosu [:valentin] (he/him) from comment #6)
which expects a similar redirect from "http://127.0.0.2" to "https://127.0.0.2" ; do we really want to keep that behavior?
I'm not sure about that. Christoph?
I am not 100% certain myself. Probably we don't want that behavior in the end and it's better to update /browser_fall_back_to_https.js to do something else for automated testing of the
https:fallback.
Just for the record, this ended up being done in bug 1672127.
|
|
||
Comment 11•4 years ago
|
||
(In reply to Valentin Gosu [:valentin] (he/him) from comment #9)
Firefox doesn't do that since there is no IPv6 entry in /etc/hosts - but it might start working once Bug 1220810 lands - since we'll synthetically generate localhost IP entries.
Just tested with Firefox Nightly 84.0a1 (2020-10-26) (64 bits) and the same behavior happens. Let's see what's happening here...
|
|
||
Comment 12•4 years ago
|
||
(In reply to Josef Markus Mitterbauer from comment #8)
@Valentin Gosu, should I attach the settings of my apache server too? It has an entry for vhost.localhost but I can also give more detailed information if required. But as far as I found out you can use any configuration of a virtual host in combination with localhost and it's not working.
(In reply to Frédéric Wang (:fredw) from comment #11)
Just tested with Firefox Nightly 84.0a1 (2020-10-26) (64 bits) and the same behavior happens. Let's see what's happening here...
Actually, I'm not sure my local config is correct to reproduce the the bug, so I think that would be helpful to get the details.
|
|
||
Comment 13•4 years ago
|
||
valentin clarified this is a WSL-specific bug (I was trying to reproduce it on linux). Let's wait for bug 1673364.
|
||
Comment 14•4 years ago
|
||
I am experiencing the same bug in Firefox 82 on Linux. I have to use incognito when I develop where this bug is not present. Clearing cache, cookies, forgetting website, changing stuff in about:config, disabling addons didn't help. This is definitely not a WSL specific bug.
|
|
Assignee | |
Comment 15•4 years ago
|
||
(In reply to Samuel Illo from comment #14)
I am experiencing the same bug in Firefox 82 on Linux. I have to use incognito when I develop where this bug is not present. Clearing cache, cookies, forgetting website, changing stuff in about:config, disabling addons didn't help. This is definitely not a WSL specific bug.
Please open a new bug for that, and attach HTTP logs
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
|
|
||
Comment 16•4 years ago
|
||
@Josef: Can you please try again with the latest Firefox Nightly build (maybe waiting tomorrow as I'm not 100% sure the patch for bug 1673364 is included in today's build)?
|
|
Reporter | |
Comment 17•4 years ago
|
||
@Frédéric Wang (:fredw) sure, I'll give it a try. Tomorrow CET I hope is "late" enough.
|
|
Assignee | |
Comment 18•4 years ago
|
||
I just tested on windows - there is still a bug somewhere. http://[::1]/ works vhost.localhost resolves to the correct IPs, but the page still doesn't load.
Looking into it.
|
|
Reporter | |
Comment 19•4 years ago
|
||
Hi, I can confirm that it's not working with build 84.0a1 (2020-10-30) (64-bit) - sorry for not replying yesterday already.
|
|
Assignee | |
Comment 20•4 years ago
|
||
2020-11-02 13:44:49.822000 UTC - [Parent 20280: Main Thread]: V/nsHttp nsHttpConnectionMgr::AddTransaction [trans=0000017F52F8E810 -20]
2020-11-02 13:44:49.822000 UTC - [Parent 20280: Main Thread]: D/nsSocketTransport STS dispatch [0000017F5FBCA240]
2020-11-02 13:44:49.822000 UTC - [Parent 20280: Main Thread]: D/nsSocketTransport PollableEvent::Signal
2020-11-02 13:44:49.822000 UTC - [Parent 20280: Main Thread]: D/nsSocketTransport PollableEvent::Signal PR_Write 1
...
2020-11-02 13:44:49.828000 UTC - [Parent 20280: Socket Thread]: D/nsSocketTransport ErrorAccordingToNSPR [in=-5986 out=804b000d]
2020-11-02 13:44:49.828000 UTC - [Parent 20280: Socket Thread]: D/nsSocketTransport connection failed! [reason=804b000d]
2020-11-02 13:44:49.828000 UTC - [Parent 20280: Socket Thread]: D/nsSocketTransport nsSocketTransportService::DetachSocket [handler=0000017F52F7F400]
2020-11-02 13:44:49.828000 UTC - [Parent 20280: Socket Thread]: D/nsSocketTransport nsSocketTransport::OnSocketDetached [this=0000017F52F7F400 cond=804b000d]
2020-11-02 13:44:49.828000 UTC - [Parent 20280: Socket Thread]: D/nsSocketTransport nsSocketTransport::RecoverFromError [this=0000017F52F7F400 state=3 cond=804b000d]
2020-11-02 13:44:49.852000 UTC - [Parent 20280: Socket Thread]: D/nsHostResolver Adding address to blocklist for host [vhost.localhost], host record [0000017F583E5C00].used trr=0
2020-11-02 13:44:49.852000 UTC - [Parent 20280: Socket Thread]: D/nsHostResolver Successfully adding address [::1] to blocklist for host [vhost.localhost].
2020-11-02 13:44:49.852000 UTC - [Parent 20280: Socket Thread]: D/nsHostResolver Checking unusable list for host [vhost.localhost], host record [0000017F583E5C00].
2020-11-02 13:44:49.852000 UTC - [Parent 20280: Socket Thread]: D/nsSocketTransport trying again with next ip address
It's still not clear to me why this fails, but connecting to [::1] succeeds. Probably some odd windows quirk.
|
|
||
Comment 21•4 years ago
|
||
@Josef @Valentin: Thanks for checking.
|
||
Comment 23•4 years ago
|
||
We always put 127.0.0.1 before ::1 when network.proxy.allow_hijacking_localhost is false. If the local server only listens ::1 (as the WSL2 case), connection will fail. We should respect the platform order of precedence. Chrome has AddressSorter to sort the address list.
|
|
Assignee | |
Comment 24•4 years ago
|
||
So, if I test with a build from the 5th of Nov it fails.
It seems to work with recent builds.
I did a mozregression and it pointed towards bug 1675587.
Josef, can you check if you can still reproduce the bug?
|
|
Reporter | |
Comment 25•4 years ago
|
||
Hi @Valentin Gosu now it works using Firefox Nightly 86.0a1 (2021-01-22) (64-bit)
|
||
Updated•4 years ago
|
|
|
Assignee | |
Comment 26•4 years ago
|
||
I'm going to mark this as fixed for now.
I needinfoed the reporter in bug 1686759 for more details, as it seems they have one setup that works and one that doesn't.
(In reply to Valentin Gosu [:valentin] (he/him) from comment #24)
So, if I test with a build from the 5th of Nov it fails.
It seems to work with recent builds.
I did a mozregression and it pointed towards bug 1675587.Josef, can you check if you can still reproduce the bug?
I am the original reporter of bug 1675587. I was led to this bug because I noticed this bug was added to that bug.
How interesting to learn that bug did have a real world implication (!)
Back when I created the patch, I was not sure. But there was an indication. As I mentioned in the bug 1675587 comment 0, I noticed that one problematic place was not flagged until I fixed the first one. Obviously the flow of the program was affected. So that change of control manifested in a subtle bug here. I am glad something that would have perplexed me to no end was fixed by a mundane uninitialized memory bug. :-)
Thank you for making firefox better. It is my browser of choice under Windows and linux.
|
|
||
Updated•3 years ago
|
Description
•