1913100 - Protocol error (only) in Firefox for a certain website due to upper-case header names (HTTP2 Push spec violation)

Status: RESOLVED FIXED

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

Description

[Adrian Mate]

Attachment: protocol error.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36

Steps to reproduce:

I'm posting here because I'm at a loss why on Firefox (and only on Firefox) a certain website cannot be accessed. The error shown is "Network Protocol Error".

To be exact, we have the website https://dev.nobilacasa.ro/ , which is accessible and loading without any issues on all major browsers, except Firefox.
The server on which the website is hosted is Windows Server 2022, running IIS10.

Upon inspecting the page, I found the error "NS_ERROR_NET_HTTP2_GOAWAY".

I tried changing SSL protocol versions, enabling/disabling ciphers on the server a.s.o. but nothing helped.

The website in question is running DynamicWeb CMS, based on .NET

P.S.

I was able to temporarily solve this issue by disabling HTTP/2 in IIS settings > Website bindings .

It seems that once I enable HTTP/2 the error comes back.

Currently, HTTP2 is enabled on the website https://dev.nobilacasa.ro in order for you to be able to reproduce the issue.

Actual results:

Protocol error "NS_ERROR_NET_HTTP2_GOAWAY" in "Inspect" -> "Network" section

Expected results:

The website https://dev.nobilacasa.ro should load just fine

Comment 2

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

Hi,

It seems that Firefox is resetting the connection because it encounters an uppercase character in the header names.
This is correct according to the HTTP/2 RFC.

https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2

However,
header field names MUST be converted to lowercase prior to their
encoding in HTTP/2. A request or response containing uppercase
header field names MUST be treated as malformed (Section 8.1.2.6).

If I may ask, what HTTP server are you using?

Note - the error we are seeing in Firefox is returned here

Comment 3

[Adrian Mate]

Hello, Valentin,

Sorry for the late reply. I was out of office for the past few days.
The website is running on Windows Server 2022 with IIS version 10.0.20348.1

Comment 4

[Alice0775 White]

FWIW,
setting network.http.http2.allow-push to false will load the page.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Sounds like there's a bug in the server/CMS/site generating the uppercase. We could allow for spec violations, and just flag them in the console. Of course, if Chrome/etc didn't allow invalid headers, the server/cms programmers would likely have fixed it long ago... :-(

Comment 6

[Adrian Mate]

Hello,

The initial problem was the fact that on ALL major browsers like Chrome, IE, Edge, Opera, Safari a.s.o. (except Firefox), the website loaded without any issues. We did not know exactly what was the reason for this behavior, that is why I submitted the bug report.
A bit of additional info would be helpful.
Is there a way to identify the string / text in which the uppercase character is in the header names?
I have access to the server where the website is hosted and I can adjust the settings.
If the header in cause is from the CMS then I'd have to report this to the developers of the CMS (DynamicWEB).

Also, maybe you could take into consideration loosening this rule a bit. Most probably other major browsers already did this.

Thank you!

Comment 7

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

Hi Adrian,

Here's a wireshark decoding of the packet causing the issue:

No.     Time           Source                Destination           Protocol Length Info
    397 7.039513321    92.114.98.98          192.168.86.31         HTTP2    531    PUSH_PROMISE[15]: GET /Files/Templates/Designs/Wizaris/manifest.json

Frame 397: 531 bytes on wire (4248 bits), 531 bytes captured (4248 bits) on interface enx04bf1b857e43, id 0
Transmission Control Protocol, Src Port: 443, Dst Port: 55258, Seq: 3783, Ack: 2513, Len: 465
Transport Layer Security
HyperText Transfer Protocol 2
    Stream: PUSH_PROMISE, Stream ID: 15, Length 434, GET /Files/Templates/Designs/Wizaris/manifest.json
        Length: 434
        Type: PUSH_PROMISE (5)
        Flags: 0x04, End Headers
        0... .... .... .... .... .... .... .... = Reserved: 0x0
        .000 0000 0000 0000 0000 0000 0000 1111 = Stream Identifier: 15
        [Pad Length: 0]
        0... .... .... .... .... .... .... .... = Reserved: 0x0
        .000 0000 0000 0000 0000 0000 0000 0010 = Promised-Stream-ID: 2
        Header Block Fragment [truncated]: 3fe11f878244a16309a82a18de5a6ba0692a18be541a6a90c7237b1d8643148ea34a54257e883d5f418c90bdd7a8f19a8190681af61f4087bc7aaa291263d5842507417f408484842d69d3497ca589d34d1f43aeba0c41a4c7a98f33a69a3fdf9a68fa1d75d0
        [Header Length: 685]
        [Header Count: 19]
        Header table size update
        Header: :scheme: https
        Header: :method: GET
        Header: :path: /Files/Templates/Designs/Wizaris/manifest.json
        Header: :authority: dev.nobilacasa.ro
        Header: Connection: close
        Header: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8
        Header: Accept-Encoding: gzip, deflate, br, zstd
        Header: Accept-Language: en-US,en;q=0.5
        Header: Host: dev.nobilacasa.ro
        Header: TE: trailers
        Header: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:131.0) Gecko/20100101 Firefox/131.0
        Header: upgrade-insecure-requests: 1
        Header: sec-fetch-dest: document
        Header: sec-fetch-mode: navigate
        Header: sec-fetch-site: none
        Header: sec-fetch-user: ?1
        Header: priority: u=0, i
        Header: X-FIREWALL-ID: 11
        [Full request URI: https://dev.nobilacasa.ro/Files/Templates/Designs/Wizaris/manifest.json]
        [Response in frame: 404]

The header causing Firefox to abort the connection is Connection: close but there are several other uppercase headers as you can see.
Since the website works with server-push disabled, I expect it's the part of your stack that is dealing with push that is causing the issues.
The reason it doesn't happen in other browsers is that Chrome removed push support a while ago.

Comment 8

[Adrian Mate]

Hi, Valentin,

Thanks for the additional information. Indeed there are many Headers that have uppercase characters in it.
As far as I know, in IIS I can't disable server-push without disabling HTTP/2 completely.
Also, many of those Headers are core IIS Headers and I can't modify them easily. Besides that, I'm sure that those settings would be overwritten at the next update of IIS.
If you have any additional suggestion on how to deal with this problem, I would be really grateful if you could let me know.

Thank you very much!

Comment 9

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

Fixed by disabling HTTP/2 push in bug 1915848.