Ne confruntăm cu un comportament de downgrade de la http2 la http1.1 al IIS 10 pe care nu îl înțelegem cu adevărat. Am implementat un API REST (frontend: Angular, backend: php (folosind laminas-api-tools). Pentru cererile noastre GET, POST și PUT, totul este în regulă. Cu toate acestea, atunci când trimitem o solicitare DELETE care ar trebui să primească răspuns prin codul de stare 204, se întâmplă următoarele:
- cererea poate fi văzută în jurnalul IIS, venind prin http/2, fiind răspuns de un 204 și win32-status 87 (adică: parametrul este incorect)
- în continuare, exact aceeași solicitare poate fi văzută din nou în jurnalul IIS, de data aceasta folosind http/1.1, fiind răspuns cu un 406 (neacceptat)
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
406 se întâmplă deoarece în prima solicitare, elementul este de fapt șters (deci a doua cerere eșuează cu „Elementul nu există”).
Într-un browser, putem vedea doar al doilea răspuns (406). Toate solicitările DELETE ulterioare (la alte elemente) funcționează bine de acolo încolo (deoarece se întâmplă peste http/1.1 pentru restul sesiunii de browser). Deși elementul a fost șters și ștergerile ulterioare funcționează impecabil, acest comportament este o experiență de utilizator foarte neplăcută.
Cu toate acestea, nu am reușit să aflăm ce cauzează de fapt acest http1.1-downgrade. Documentele IIS spun doar următoarele (de la https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10/http2-on-iis#when-is-http2-not-supported):
Când HTTP/2 nu este acceptat?
În câteva cazuri, HTTP/2 nu poate fi utilizat în combinație cu altele
Caracteristici. În aceste situații, Windows va reveni la HTTP/1.1 și
continua tranzactia. Acest lucru poate implica negocierea HTTP/1.1 în timpul
strângerea de mână sau trimiterea unui cod de eroare clientului care îl instruiește
pentru a reîncerca printr-o conexiune HTTP/1.1.
- Autentificarea Windows (NTLM/Kerberos/Negotiate) nu este acceptată cu HTTP/2. În acest caz, IIS va reveni la HTTP/1.1.
- Text clar - așa cum sa menționat mai sus, IIS acceptă în prezent numai HTTP/2 prin TLS. Din nou, IIS va reveni la HTTP/1.1.
- Limitarea lățimii de bandă - IIS are o caracteristică pentru a limita lățimea de bandă (în Inetmgr, selectați site-ul, „Limite” sub Configurarea acțiunii
panou). Acest lucru se aplică pentru HTTP/1.1, dar nu este aplicat pentru HTTP/2 (Will
procedați fără erori sau limitarea lățimii de bandă).
Cu toate acestea, nici nu folosim autentificarea Windows (dacă da, orice apel API ar eșua, nu doar DELETE) și nici limitarea lățimii de bandă. De asemenea, mi se pare foarte puțin probabil ca subiectul „text clar” să joace un rol pentru noi, deoarece orice comunicare are loc prin https/TLS.
Deci trebuie să fie o altă cauză.
Am analizat și răspunsul de la lamine, dar nu am reușit să găsim posibile explicații - ceea ce am aflat este că trimiterea unui cod de stare diferit de 204 rezolvă de fapt problema. Aceasta este soluția noastră actuală: trimiteți 200 în loc de 204 ca cod de răspuns DELETE.
Cu toate acestea, credem că ar fi mai degrabă o bună practică pentru utilizatorul 204.
Alte surse de cercetare au inclus:
Ne poate ajuta cineva să înțelegem ce poate cauza problema aici?
Multumesc mult anticipat, Jan
