Artykuł z serii „notatki na marginesach”.
TL:DR:
http2_max_field_size 8k; # wszyscy będą uratowani!W jednym z projektów, po zmianie niektórej wewnętrznej logiki zaplecza, zacząłem obserwować dziwny response_code w logach, a mianowicie — 0. W logach wygląda to mniej więcej tak:
{
"timestamp": "2020-01-17T08:41:51+00:00",
"remote_addr": "zzz.zzz.zzz.zzz",
"request_time": 0,
"upstream_response_time": "",
"upstream_header_time": "",
"http_accept_language": "-language",
"response_status": 0,
"request": "",
"host": "example.com",
"upstream_addr": "",
"http_referrer": "",
"request_length": 5854,
"bytes_sent": 0,
"http_user_agent": ""
}
Czytanie dokumentacji i googlowanie na ten temat nic nie dało — ponieważ stwierdzono, że takie zachowanie występuje, gdy klient zamknął połączenie, nie przesyłając nagłówków. No i różnorodne egzotyki z rozmiarem bufora dla wsgi_, co w naszym przypadku nie pasowało wcale.
Ogólnie rzecz biorąc, postanowiliśmy, że problem — nie problem, biorąc pod uwagę, że w naszych warunkach to zupełnie nie jest krytyczne.
Aż do momentu, gdy nie zaskoczyła mnie następująca kwestia: w niektórych przypadkach linki bez problemu otwierają się przez http, ale całkowicie odmawiają działania przez https, dając cudowny komunikat: Connection #0 to host example.com left intact
curl: (52) Pusta odpowiedź od serwera
W logach udało się zidentyfikować tę rzecz tylko po IP — nie było rekuesu ani żadnych innych danych, jak widać z powyższego przykładu — nie ma. Tylko nieszczęsny status 0, ale ja wiem, że nie przerwałem zapytania! Zacząłem grzebać, co może pójść nie tak. A wszystko okazało się bardzo proste:
listen 443 ssl http2 backlog=8192;
No więc — jeśli stosujesz http2 dla połączeń ssl, to niewystarczające jest tylko konfigurowanie buforów zapytań, trzeba je również skonfigurować w ngx_http_v2_module, a mianowicie:
Składnia: http2_max_field_size rozmiar;
Domyślnie: http2_max_field_size 4k;
Kontext: http, server
Ogranicza maksymalny rozmiar nagłówka zapytania skompresowanego za pomocą HPACK. Ograniczenie stosuje się zarówno do nazwy, jak i do wartości. Jeśli używa się kodowania Huffmana, rzeczywisty rozmiar rozpakowanych ciągów nazw i wartości może być większy. Domyślne ograniczenie jest odpowiednie dla większości zapytań.
Ogólnie rzecz biorąc, to to. A wszystko dlaczego? Ponieważ długość linku była duża — większa niż te 4k.
Ustalając go na przykład na 8kb (lub tyle, ile na pewno wystarczy) — rozwiązujemy problem.
Takie sprawy.
Źródło: habr.com
