Authorized H2 proxies cause networking to stall
Categories
(Core :: Networking, defect)
Tracking
()
People
(Reporter: yegors, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36
Steps to reproduce:
- Load a basic Pac file that references an authorized proxy
- Enter proxy credentials into the popup
- Load any Youtube/Netflix video and skip to parts that have not yet buffered in rapid succession
Actual results:
Youtube (or any other streaming service) will be stuck in a buffering state for anywhere from 1 to 30+ seconds.
The same issue occurs if you use the proxy.onRequest API instead of the Pac file.
If you use an unauthenticated proxy, the issue does not occur and functions identically to Chrome.
Additionally, if you disable spdy in about:config, or disable H2 on the proxy server itself, the issue does not occur even with authorized proxies
This appears to be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1556005
Downloading at high speed (streaming video or doing speed tests on Fast.com) seems to trigger the problem.
Expected results:
Requests should not hang in any scenario.
Hi Yegors,
I'll add a product and component to this ticket so the devs can take a look at it. If you think this is not the right component feel free to change it.
Thank you for your report.
|
||
Comment 2•5 years ago
|
||
Could is a duplicate of bug 1554218, I believe.
@Virginia Yeah, all good.
@Honza It is not. Auth works, the performance with H2 proxies is extremely sub-par compared to Chromium. Your issue is likely related to a 407 being thrown for a HTTPS request, which is not handled the same way as over HTTP.
Currently we're forced to operate http1.1 proxies in parallel with H2 ones, and use them for our Firefox users until this issue is resolved.
|
|
||
Comment 4•5 years ago
|
||
Updated bug 1554218, we don't handle 407 from an h2 proxy when you are connecting secure servers. Going to plain URL does pop-up an auth dialog; since then we remember the credentials if it's just Basic auth (NTLM is not supported at all, even by h2).
I'm still not sure if the authentication is not just a red herring here, but we'll see.
I have fixed few issues regarding perf issues around h2 proxies quite recently. Would you be willing to test with the latest Nightly (scroll to bottom)?
I also have an experimental build with one more fix added (still a draft, tho) here: zip or installer; based on the current Release (68).
If we remove server side authentication, the H2 proxies function identically to Chromium, or authed http1.1 proxies in Firefox. With no performance degradation.
I'll try the nightly + experimental builds later on today. Here is a dev build of our extension, a free account can be created during the on-boarding (no email required) in order for proxies to be tested: https://send.firefox.com/download/8124ca21ea26549c/#8rBpnH6asrEjgxIzLlBInQ
Then follow the "Steps to reproduce" in the original post.
|
|
||
Comment 6•5 years ago
|
||
yegors, I'd like to ask you to test again with the current Nightly. we have fixed number of bugs literally few days ago and I wonder if those might help fixing the issues you reported as well.
thanks!
Honza, I'm pleased to say the issue appears to be resolved! Everything is nice and fast, no perceivable lag or stalling is occurring.
When will these changes make it into the release branch?
|
|
||
Comment 8•5 years ago
|
||
They are all already on Nightly and Beta.
|
|
||
Comment 10•5 years ago
|
||
(In reply to yegors from comment #9)
So this will be in the August release of FF 69?
Yes!
Marking as WFM, please open new bugs if you find new issues, thanks for this report!
Description
•