On this page: https://support.mozilla.org/en-US/questions/1290085 the issue is also reported and "resolved" by changing settings in IIS such that HTTP/2 is no longer used.

I am experiencing the same issue on a shared hosting service where disabling HTTP/2 is a "no go", so I would like to have the issue actually fixed. I see the same symptoms as reported on the mentioned page and in this bug and was able to check the following:

• Using other browsers than Firefox (i.e. Edge, Chrome, Safari), the issue cannot be reproduced
• When making the request via HTTP (non-SSL) with Firefox, the issue cannot be reproduced
• Using different certificate suppliers (used Let's Encrypt and Sectigo) on the server does not change the behaviour: issue can be reproduced in both cases

Thus, it means that it is really a Firefox issue, when using HTTP/2 via HTTPS.

I am using the latest stable version of Firefox (version 80) on Windows 10

Currently, with the latest official release, version 83, on Windows 10 I have tested and narrowed it down to some certain cases.

I have set up a small test web site on IIS 10.0, using Perl scripts and using the Perl CGI.pm module to create the reponse. The script adds a record to a simple database every time it is executed. It will then report in the response (in simple text) how many times it was executed from the same IP address within the last 5 seconds.

Now I have found the following, using this setup:

• When the script is named nph-<something>.pl and CGI.pm is instructed to generated headers according to the Non-parsed headers CGI definition, AND the script is executed via HTTPS, the script is executed twice
• When the script is named <something>.pl (without the "nph-") and CGI.pm is instructed to generate headers according to the Non-parsed headers CGI definition, AND the script is executed via HTTPS, the script is executed once.
• When the script is executed via HTTP (insecure), the script is executed once.

Having said this, the double execution only happens with Firefox (only tested on Windows), but not with Edge, Chrome or Safari (on iOS). Other browsers I did not test.

The strange thing is that in the Network-tab of the Developer Tools, only one request is listed (the original one) and (in my case) only one entry is logged in the IIS server logs. This makes me wonder what is happening here. I do not have access to the system IIS logs (I am on a hosting provider with limited access/configuration possibilities), so I do not know what is happening under the hood why the script is executed twice. On the other hand, since it only happens with Firefox, there seems to be something in the Firefox request that makes this happen.

The test scripts can be accessed via the following URLs (until further notice):

• http(s)://ff.famversteeg.nl/nph (for the script that starts with "nph-" and is executed twice when accessed via HTTPS)
• http(s)://ff.famversteeg.nl/non-nph (for the script that does not start with "nph-" and is executed once)

How can I support in being able to debug/solve this issue? There seems to be a work-around (renaming all my scripts), but I prefer not to do that for one single browser as that requires a lot of additional testing.

Hi Marcel, I'd suggest to try to record the network traffic with wireshark or similar. This allows you to see:

• if there are really two requests
• if there are any differences in the requests sent dependending on the naming and/or the browser used
• if there are any differences in the responses sent from IIS depending on the naming and/or the browser used
  There is a never clarified suspect in bug 1411193 that this might be more a server side configuration problem and an in-depth analysis of the traffic might help to understand this.
  Thank you for your support

Hi Jens,

Using Wireshark I saw the following happen when requesting the script that starts with "nph-" in Firefox:

1. There is a TLS handshake between the browser and the server
2. Then Firefox does a HTTP2 request to the server
3. Then IIS sends back a HTTP2 response saying: "Error: HTTP_1_1_REQUIRED (13)"
4. Then Firefox does a HTTP/1.1 request to the server (which is not shown in the Network tab of the developer tools)
5. The correct response from the script is sent back.
   This happens for every HTTPS request done to this script.
   I did test again with Microsoft Edge and found out that when I completely clear its cache and restart the browser and request the NPH script, Edge does the same thing. The difference is that Edge remembers it should use HTTP/1.1 for the following requests and does not do a HTTP2 request anymore.

When I make a trace in Wireshark of the request to the script that does not start with "nph-" the the following happens:

1. There is a TLS handshake between the browser and the server
2. Then Firefox does a HTTP2 request to the server
3. Then IIS sends the correct response

The strange thing is, that in both situations CGI.pm is instructed to do NPH, but for some reason this is ignored by IIS because the script does not start with "nph-".

So my conclusion is as follows:

1. It would be nice if Firefox remembers that it should not retry a HTTP2 request once a HTTP_1_1_REQUIRED response is received for a specific server/URL
2. I need to find a way to handle HTTP2 correctly in my scripts.

Thank you for the hint of using Wireshark for tracing.

The underlying problem/unexpected behavior seems to have its root cause on the server side. Nevertheless I filed bug 1679494 to check whether we should cache this particular error response.

(In reply to Marcel V from comment #8)

The test scripts can be accessed via the following URLs (until further notice):

• http(s)://ff.famversteeg.nl/nph (for the script that starts with "nph-" and is executed twice when accessed via HTTPS)
• http(s)://ff.famversteeg.nl/non-nph (for the script that does not start with "nph-" and is executed once)

This is just to let people know that I have taken down these test scripts