Closed Bug 1670146 Opened 4 years ago Closed 4 years ago

Calling virtual host (e.g. http://vhost.localhost) automatically redirects to https://vhost.localhost

Categories

(Core :: Networking, defect, P2)

Firefox 81
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox84 --- fixed

People

(Reporter: jmpc, Assigned: valentin, NeedInfo)

References

Details

(Whiteboard: [necko-triaged][fixed by bug 1675587])

Attachments

(2 files)

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.

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.

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.

Component: Untriaged → Networking
Product: Firefox → Core

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.

Severity: -- → S3
Priority: -- → P2
Whiteboard: [necko-triaged]

Note - the upgrade to https happens because loading http://vhost.localhost fails.

(In reply to Valentin Gosu [:valentin] (he/him) from comment #4)

Note - the upgrade to https happens because loading http://vhost.localhost fails.

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?

Flags: needinfo?(valentin.gosu)

(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.localhost fails.

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?

Flags: needinfo?(valentin.gosu) → needinfo?(ckerschb)

(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.

Flags: needinfo?(ckerschb)

@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.

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.

(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.

(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...

(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.

Flags: needinfo?(jmpc)

valentin clarified this is a WSL-specific bug (I was trying to reproduce it on linux). Let's wait for bug 1673364.

Flags: needinfo?(jmpc)

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.

(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

Flags: needinfo?(lamka02sk)

@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)?

Flags: needinfo?(jmpc)

@Frédéric Wang (:fredw) sure, I'll give it a try. Tomorrow CET I hope is "late" enough.

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.

Assignee: nobody → valentin.gosu
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(lamka02sk)
Flags: needinfo?(jmpc)

Hi, I can confirm that it's not working with build 84.0a1 (2020-10-30) (64-bit) - sorry for not replying yesterday already.

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.

@Josef @Valentin: Thanks for checking.

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.

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?

Flags: needinfo?(jmpc)

Hi @Valentin Gosu now it works using Firefox Nightly 86.0a1 (2021-01-22) (64-bit)

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.

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
See Also: → 1675587

(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.

Depends on: 1675587
See Also: 1675587
Whiteboard: [necko-triaged] → [necko-triaged][fixed by bug 1675587]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: