"Unexpected response from server" regression on certain sites with proxy addon, DoH and no networkPredictionEnabled
Categories
(Core :: Networking: HTTP, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox94 | --- | fixed |
People
(Reporter: dennis.lissov, Assigned: kershaw)
References
Details
(Whiteboard: [necko-triaged])
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0
Steps to reproduce:
- Find/create a SOCKS proxy that can be used for the test, for example, using SSH
ssh -D 8888 proxy_hostname - Launch a fresh Firefox profile with
mozregression --launch 2021-09-25 - Go to Settings and enable DNS over HTTPS
- Go to about:debugging and install a stub WebExtension (attached; please unzip, it seems to make some difference for the first point) that does two things:
- forces privacy.network.networkPredictionEnabled to false (so that network.http.speculative-parallel-limit becomes 0)
- install a browser.proxy.onRequest handler that for every request awaits 200 ms and then directs it to no proxy (mozilla.cloudflare-dns.com) or SOCKS 127.0.0.1:8888 (anything else)
- Visit https://www.teslaoracle.com/ and try refreshing that page (up to a dozen or so times)
Actual results:
Sometimes (not every time) instead of the page the following reply is seen:
Unexpected response from server
Firefox doesn’t know how to communicate with the server.
Check to make sure your system has the Personal Security Manager installed.
This might be due to a non-standard configuration on the server.
Expected results:
With a reliable proxy this configuration should work reliably.
I've bisected this bug with mozregression twice with different results:
On a fresh profile (as described in the STR above), it finishes with
44:23.54 INFO: Last good revision: 94623c136e66f88f709e8aaf43dc1c556f4881cc
44:23.54 INFO: First bad revision: adf68ff22830f6a0dc94a52e421d916244b3192c
44:23.54 INFO: Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=94623c136e66f88f709e8aaf43dc1c556f4881cc&tochange=adf68ff22830f6a0dc94a52e421d916244b3192c
which points to bug 1714506 (and, indeed, disabling network.dns.force_waiting_https_rr fixes the problem).
In a clone of my main profile with my proxy addon instead of this stub (initial bisection), it finished at bug 1726528 instead. That roughly corresponds to the moment when I started noticing the problem in my daily browsing. My main profile has HTTP3 disabled, and it seems that disabling it fixes the problem on Nightly 2021-09-15, but not on Nightly 2021-09-25.
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Security' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•3 years ago
|
||
Moving across to Core/Networking: HTTP as that's where the bugs referenced are. Kershaw, could you take a look? This might need to move across to WebExtensions, but I don't know enough.
Assignee | ||
Comment 3•3 years ago
|
||
The problem here is that we tried to connect to SOCKS proxy with http3
, which should be disallowed.
At this line, when http3
is not allowed because of proxy, we didn't set NS_HTTP_DISALLOW_HTTP3
.
I'll submit a patch to fix this soon.
Assignee | ||
Comment 4•3 years ago
|
||
Pushed by kjang@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/863ef8612787 Make sure NS_HTTP_DISALLOW_HTTP3 is set when proxy is used, r=necko-reviewers,dragana
Comment 6•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Comment 7•2 years ago
|
||
Hi Denis! Could you please verify if this bug is fixed on 94.0 RC2, on your end?
I've reproduced the Unexpected response from server
error message which was displayed on a broken Firefox build, but didn't follow your exact steps, since I don't know for sure how to use a SOCKS proxy on Ubuntu. Instead, I've configured one in Firefox as explained here, however, I'm getting the warning The proxy server is refusing connections
when accessing https://www.teslaoracle.com/ on a fixed 94.0 RC2 build. So, perhaps this may not be the correct way to test it.
Reporter | ||
Comment 8•2 years ago
|
||
Sorry, my steps to reproduce for this rely on loading a custom addon, which is unsigned and thus probably cannot be loaded in a release channel RC. However, I stopped seeing this problem in my daily browsing (on Nightly) after this bug's patch landed and I cannot reproduce it on Nightly anymore, so it likely has been fixed.
Description
•