1915134 - Add pref to enable Extensible Prioritization Scheme without sending SETTINGS_NO_RFC7540_PRIORITIES

Status: VERIFIED FIXED

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

Description

[Valentin Gosu [:valentin] (he/him)]

In Bug 1909666 we re-enabled network.http.http2.enabled.deps due to instances of site breaking.
The sites were breaking because we were sending the SETTINGS_NO_RFC7540_PRIORITIES option.
We should add a separate pref whether to send that, so we can set network.http.http2.enabled.deps to false and not send the option.
It's unclear whether servers will respond to the stream weight dependencies or the Priority header when that happens, but it does make us move forward with this.

Comment 1

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1915134 - Add pref to enable Extensible Prioritization Scheme without sending SETTINGS_NO_RFC7540_PRIORITIES r=acreskey

Comment 2

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1915134 - Flip network.http.http2.enabled.deps to false r=acreskey

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e824a4a58de7
Add pref to enable Extensible Prioritization Scheme without sending SETTINGS_NO_RFC7540_PRIORITIES r=acreskey,necko-reviewers,jesup
https://hg.mozilla.org/integration/autoland/rev/2f6a4acf69b2
Flip network.http.http2.enabled.deps to false r=acreskey

Comment 4

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/e824a4a58de7
https://hg.mozilla.org/mozilla-central/rev/2f6a4acf69b2

Comment 5

[Hamish Willee]

My understanding is that

• in FF128 we enabled "Implement Extensible Prioritization Scheme for HTTP/2". There were some issues reported in bug linked from https://bugzilla.mozilla.org/show_bug.cgi?id=1865040#c11, but this remained enabled.
• FF132 this has been disabled again in this issue by switching network.http.http2.enabled.deps pref to false.

1. Is that right?
2. Is the new pref network.http.http2.send_NO_RFC7540_PRI notable, given it is default on?
3. Is there an intent to re-enable this soon?

Comment 6

[Valentin Gosu [:valentin] (he/him)]

(In reply to Hamish Willee from comment #5)

My understanding is that

• in FF128 we enabled "Implement Extensible Prioritization Scheme for HTTP/2". There were some issues reported in bug linked from https://bugzilla.mozilla.org/show_bug.cgi?id=1865040#c11, but this remained enabled.
• FF132 this has been disabled again in this issue by switching network.http.http2.enabled.deps pref to false.

1. Is that right?
2. Is the new pref network.http.http2.send_NO_RFC7540_PRI notable, given it is default on?
3. Is there an intent to re-enable this soon?

1. Bug 1865040 shipped in 128, but due to regressions we flipped network.http.http2.enabled.deps back to true in bug 1909666 (which got uplifted to 128). We determined that the regressions were most likely caused by the HTTP/2 Push part of the patches, so we disabled HTTP/2 Push in bug 1915848. This bug again disables the pref old HTTP/2 stream dependencies.
2. No, it's just a safety pref in case servers misbehave when receiving the new settings parameter.
3. We didn't send an intent to ship mostly because this was partly shipped in previous builds - The priority header in bug 1865394 and HTTP/3 priority update frames in bug 1734132

Comment 7

[Hamish Willee]

All of that means (as far as I can tell) no need for any docs changes. Thank you.

Comment 8

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1915134 - Add pref to enable Extensible Prioritization Scheme without sending SETTINGS_NO_RFC7540_PRIORITIES r=acreskey

Original Revision: https://phabricator.services.mozilla.com/D220389

Comment 9

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1915134 - Add pref to enable Extensible Prioritization Scheme without sending SETTINGS_NO_RFC7540_PRIORITIES r=acreskey

Original Revision: https://phabricator.services.mozilla.com/D220389

Comment 10

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1915134 - Flip network.http.http2.enabled.deps to false r=acreskey

Original Revision: https://phabricator.services.mozilla.com/D220390

Comment 11

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: Websites that implement HTTP/2 Push incorrectly might not work in Firefox but work in other browsers
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Check that bug 1913100 and bug 1909271 don't reproduce.
• Risk associated with taking this patch: lowish
• Explanation of risk level: These specific patches have already been on Release for a few weeks without regressions, but there's a small chance it causes unexpected issues on ESR.
• String changes made/needed: none
• Is Android affected?: yes

Comment 12

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/9b3877326b8d
https://hg.mozilla.org/releases/mozilla-esr128/rev/7532dde4e235

Comment 13

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Reproduced the issue with Firefox 130.0a1 (2024-07-22) on Windows 10 x64 by following the suggested steps in comment 11 to open pages from bug 1913100 and bug 1909271. The https://www.mapbusinessonline.com/ and https://dev.nobilacasa.ro/ webpages do not load.
The pages are correctly loaded with Firefox 134.0a1 (2024-11-19), 133.0, 132.0.2 and 128.5.0esr on Windows 10x64, macOS 12 and Ubuntu 24.
Note that I encountered bug 1932308 when testing this.