1732584 - "Unexpected response from server" regression on certain sites with proxy addon, DoH and no networkPredictionEnabled

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P2)

Description

[Denis Lisov]

Attachment: [e-mail]

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

Steps to reproduce:

0. Find/create a SOCKS proxy that can be used for the test, for example, using SSH
   ssh -D 8888 proxy_hostname
1. Launch a fresh Firefox profile with
   mozregression --launch 2021-09-25
2. Go to Settings and enable DNS over HTTPS
3. 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)

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

[BugBot [:suhaib / :marco/ :calixte]]

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

[Mark Banner (:standard8)]

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.

Comment 3

[Kershaw Chang [:kershaw]]

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.

Comment 4

[Kershaw Chang [:kershaw]]

Attachment: Bug 1732584 - Make sure NS_HTTP_DISALLOW_HTTP3 is set when proxy is used, r=#necko

Comment 5

[Pulsebot]

Pushed by [e-mail]:
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

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/863ef8612787

Comment 7

[Ciprian Georgiu, Desktop QA]

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.

Comment 8

[Denis Lisov]

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.