Мы наблюдаем переход с http2 на http1.1 на более раннюю версию IIS 10, который мы на самом деле не понимаем. Мы реализовали REST API (frontend: Angular, backend: php (используя laminas-api-tools). Для наших запросов GET, POST и PUT все в порядке. Однако, когда мы отправляем запрос DELETE, на который должен быть дан ответ по коду состояния 204 происходит следующее:
- запрос можно увидеть в журнале IIS, поступающий через http/2, на который отвечает 204 и статус win32 87 (что означает: параметр неверен)
- затем точно такой же запрос снова можно увидеть в журнале IIS, на этот раз с использованием http/1.1, на который ответили 406 (не принято)
2022-03-02 13:29:38 192.168.76.64 УДАЛИТЬ /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 УДАЛИТЬ /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
Ошибка 406 возникает из-за того, что в первом запросе элемент фактически удаляется (поэтому второй запрос завершается с ошибкой «Элемент не существует»).
В браузере мы можем видеть только второй ответ (406). Все последующие запросы DELETE (к другим элементам) с этого момента работают нормально (поскольку они выполняются через http/1.1 для остальной части сеанса браузера). Несмотря на то, что элемент был удален, а последующие удаления работают безупречно, такое поведение очень неприятно для пользователя.
Однако нам не удалось выяснить, что на самом деле вызывает этот http1.1-downgrade. Документы IIS говорят только следующее (от https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10/http2-on-iis#when-is-http2-не поддерживается):
Когда HTTP/2 не поддерживается?
В некоторых случаях HTTP/2 нельзя использовать в сочетании с другими
Особенности. В этих ситуациях Windows вернется к HTTP/1.1 и
продолжить транзакцию. Это может включать согласование HTTP/1.1 во время
рукопожатие или отправка кода ошибки клиенту, инструктирующего его
для повторной попытки через соединение HTTP/1.1.
- Аутентификация Windows (NTLM/Kerberos/Negotiate) не поддерживается с HTTP/2. В этом случае IIS вернется к HTTP/1.1.
- Открытый текст — как упоминалось выше, в настоящее время IIS поддерживает только HTTP/2 через TLS. Опять же, IIS вернется к HTTP/1.1.
- Регулирование пропускной способности — IIS имеет функцию ограничения пропускной способности (в Inetmgr выберите сайт, «Ограничения» в разделе «Настройка действия»).
панель). Это относится к HTTP/1.1, но не применяется к HTTP/2 (будет
продолжить работу без ошибок или ограничения пропускной способности).
Однако мы не используем ни аутентификацию Windows (если это так, то любой вызов API завершится ошибкой, а не только DELETE), ни регулирование полосы пропускания. Кроме того, я считаю маловероятным, что тема «открытого текста» играет для нас роль, потому что любое общение происходит через https/TLS.
Значит, это должна быть какая-то другая причина.
Мы также проанализировали ответ от laminas, но не смогли найти возможных объяснений — мы выяснили, что отправка кода состояния, отличного от 204, на самом деле решает проблему. Это наше текущее решение: отправить 200 вместо 204 в качестве кода ответа DELETE.
Однако мы думаем, что вместо этого было бы лучше использовать пользователя 204.
Другие источники для исследования включали:
Может ли кто-нибудь помочь нам понять, что может вызвать проблему здесь?
Заранее большое спасибо, Ян
