Closed Bug 1732584 Opened 4 months ago Closed 4 months ago

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


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

Firefox 94



94 Branch
Tracking Status
firefox94 --- fixed


(Reporter: dennis.lissov, Assigned: kershaw)


(Whiteboard: [necko-triaged])


(2 files)

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

Steps to reproduce:

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

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.

Component: Untriaged → Security

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.

Component: Security → Networking: HTTP
Flags: needinfo?(kershaw)
Product: Firefox → Core

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: nobody → kershaw
Severity: -- → S3
Flags: needinfo?(kershaw)
Priority: -- → P2
Whiteboard: [necko-triaged]
Pushed by
Make sure NS_HTTP_DISALLOW_HTTP3 is set when proxy is used, r=necko-reviewers,dragana
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 94 Branch
Flags: qe-verify+

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 on a fixed 94.0 RC2 build. So, perhaps this may not be the correct way to test it.

Flags: needinfo?(dennis.lissov)

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.

Flags: needinfo?(dennis.lissov)
You need to log in before you can comment on or make changes to this bug.