Unable to load https://doc.smeg.it/qr/91477B344/FR when http2.allow-push=false
Categories
(Core :: Networking: HTTP, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr128 | 133+ | fixed |
| firefox130 | --- | unaffected |
| firefox131 | --- | unaffected |
| firefox132 | --- | fixed |
People
(Reporter: gerard-majax, Assigned: valentin)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files, 1 obsolete file)
Earlier today I was trying to load https://doc.smeg.it/qr/91477B344/FR and could not (Nightly, tarball, Linux). Several colleagues could reproduce, including :calixte who ran mozregression and tracked to bug 1915848. Stable (as a Snap) and Chromium were working, while at the same time Nightly was not.
Absolutely nothing was present in devtools when trying to debug that.
Switch the pref to true instantly made the URL work again, but reverting it to false still makes it working for the moment. There may be connection-reuse involved?
|
||
Comment 1•8 months ago
|
||
Set release status flags based on info from the regressing bug 1915848
:valentin, since you are the author of the regressor, bug 1915848, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
|
Assignee | |
Comment 2•8 months ago
|
||
This is a server bug caused by Firefox sending SETTINGS_TYPE_MAX_CONCURRENT = 0 when push is disabled.
The spec allows it, but Chrome doesn't do that, and server implementations are broken 🙁
I'll post a patch to match Chrome's behaviour
This server seems to be running Microsoft-HTTPAPI/2.0 🤷
|
|
Assignee | |
Comment 3•8 months ago
|
||
pcap of the bug reproducing.
|
|
Assignee | |
Comment 4•8 months ago
|
||
|
||
Comment 6•8 months ago
|
||
| bugherder | ||
|
|
Assignee | |
Updated•7 months ago
|
|
|
Assignee | |
Comment 7•7 months ago
|
||
|
|
Assignee | |
Comment 8•6 months ago
|
||
|
||
Updated•6 months ago
|
|
|
||
Comment 9•6 months ago
|
||
esr128 Uplift Approval Request
- User impact if declined: Potential HTTP/2 websites failing to load with Fortigate SSL inspection or specific HTTP server implementations
- Code covered by automated testing: no
- Fix verified in Nightly: yes
- Needs manual QE test: yes
- Steps to reproduce for manual QE testing: See bug 1919750 comment 0
- Risk associated with taking this patch: Risk is low to none
- Explanation of risk level: I should have requested uplift along with bug 1915848. This change aligns us with Chrome, and avoids triggering web servers that implement HTTP/2 incorrectly.
- String changes made/needed: none
- Is Android affected?: yes
|
||
Comment 10•6 months ago
|
||
This will be uplifted now for 128.6esr and then uplifted to a separate branch for 128.5.1esr
|
|
||
Updated•6 months ago
|
|
||
Updated•6 months ago
|
|
||
Comment 11•6 months ago
|
||
| uplift | ||
|
|
||
Comment 12•6 months ago
|
||
| uplift | ||
|
|
||
Comment 13•6 months ago
|
||
FIREFOX_ESR_128_5_X_RELBRANCH
https://hg.mozilla.org/releases/mozilla-esr128/rev/a6cdcd2ed9ec3e256f358010672bafd1674b0b8b
|
||
Comment 14•6 months ago
•
|
||
Unfortunately QA is unable to reproduce the issue using old builds without the fix thus we can't verify if this is indeed fixed or not. The URL from comment 0 loads without issues regardless the value of the network.http.http2.allow-push pref. We also checked the latest ESR build 128.5.1 with the fix and we got the same behavior.
Builds used:
Nightly from 2024-09-19 (.tar.bz2 & .deb)
ESR 128.5.0 20241118130310 (.tar.bz2 & .deb)
Hardware/Software used:
2 x Ubuntu 22.04 VM and physical machines
1 x Ubuntu 24.04
If there are any other specific steps to reproduce this please let me know and I'll try again, but till then I'll remove the qa-verify+ flag based on the above.
Description
•