0

We are experiencing a http2-to-http1.1 downgrade behaviour of IIS 10 we do not really understand. We have implemented a REST API (frontend: Angular, backend: php (using laminas-api-tools). For our GET, POST and PUT requests, everything is fine. However, when we send a DELETE request that is supposed to be answered by status code 204, the following happens:

  • the request can be seen in the IIS log, coming via http/2, being answered by a 204 and win32-status 87 (meaning: the parameter is incorrect)
  • next, the exact same request can be seen again in the IIS log, this time using http/1.1, being answered with a 406 (not accepted)
    2022-03-02 13:29:38 192.168.76.64 DELETE /myapplication/90/public/api/v1/elements/7 - 443 - 10.0.0.21 HTTP/2 Mozilla/5.0+(Macintosh;+Intel+Mac+OS+X+10_15_7)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/98.0.4758.109+Safari/537.36 https://my.server.de/myapplication/90/public/ui/elements 204 0 87 125
    2022-03-02 13:29:39 192.168.76.64 DELETE /myapplication/90/public/api/v1/elements/7 - 443 - 10.0.0.21 HTTP/1.1 Mozilla/5.0+(Macintosh;+Intel+Mac+OS+X+10_15_7)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/98.0.4758.109+Safari/537.36 https://my.server.de/myapplication/90/public/ui/elements 406 0 0 189
The 406 happens because in the first request, the element is actually deleted (so the second request fails with "Element does not exist").

In a browser, we can only see the second response (the 406). All subsequent DELETE requests (to other elements) are working fine from there on (because they happen over http/1.1 for the rest of the browser session). Although the element has been deleted and the subsequent deletions work flawlessly, this behaviour is very unpleasant user experience.

However, we were unable to find out what actually causes this http1.1-downgrade. The IIS docs only say the following (from https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10/http2-on-iis#when-is-http2-not-supported):

When is HTTP/2 Not Supported?

In a few cases, HTTP/2 can't be used in combination with other features. In these situations, Windows will fall back to HTTP/1.1 and continue the transaction. This may involve negotiating HTTP/1.1 during the handshake, or sending an error code to the client instructing it to retry over an HTTP/1.1 connection.

  • Windows authentication (NTLM/Kerberos/Negotiate) is not supported with HTTP/2. In this case IIS will fall back to HTTP/1.1.
  • Clear text - as mentioned above, IIS currently only supports HTTP/2 over TLS. Again, IIS will fall back to HTTP/1.1.
  • Bandwidth throttling - IIS has a feature to limit bandwidth (in Inetmgr, select the site, 'Limits' under Configure of the Action pane). This applies to HTTP/1.1 but is not enforced for HTTP/2 (will proceed with no errors or bandwidth limiting).

However, neither are we using windows authentication (if so, any API call would fail, not just DELETEs) nor bandwidth throttling. Also, I find it highly unlikely that the "clear text" topic plays a role for us, because any communication happens via https/TLS.

So it must be some other cause.

We also analyzed the response from laminas but were not able to find possible explanations - what we found out is that sending a status code different from 204 actually solves the problem. That is our current solution: send 200 instead of 204 as the DELETE response code.

However, we think it would be more of a best practice to user 204 instead.

Other sources for research included:

Can anybody help us in understanding what may cause the issue here?

Thanks a lot in advance, Jan

JanJanJan
  • 1

0 Answers0