En artikel fra kategorien "sidenoter".
TL: DR:
http2_max_field_size 8k; # всех спасет!På et af projekterne, efter at have ændret noget intern logik i backend, begyndte jeg at observere en mærkelig response_code i loggene, nemlig 0. I loggene ser det sådan ud:
{
"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": ""
}
At læse dokumentationen og google om dette emne gav absolut intet - fordi... Det er angivet, at denne adfærd opstår, når klienten lukkede forbindelsen uden at sende overskrifterne. Nå, og diverse eksotiske ting med bufferstørrelsen til wsgi_, som i vores tilfælde ikke passede til ordet "på nogen måde".
Generelt besluttede vi, at problemet ikke er et problem, under hensyntagen til, at det på vores volumener slet ikke er kritisk.
Præcis indtil jeg blev forundret over følgende problem: i nogle tilfælde åbnes links uden problemer via http, men nægter fuldstændig at arbejde via https, hvilket producerer den vidunderlige: Forbindelse #0 til værten eksempel.com forbliver intakt
curl: (52) Tomt svar fra server
I logfilerne kunne vi kun spore denne ting via IP - der var ingen anmodning eller andre data, som det kan ses af eksemplet ovenfor. Kun den berygtede status er 0, men jeg ved, at jeg ikke afbrød anmodningen! Jeg begyndte at finde ud af, hvad der kunne gå galt. Og alt viste sig at være meget enkelt:
lyt 443 ssl http2 backlog=8192;
Tja, hvis du bruger http2 til ssl-forbindelser, så er det ikke nok bare at konfigurere anmodningsbufferne, de skal også konfigureres i ngx_http_v2_module, nemlig:
Синтаксис: http2_max_field_size размер;
Умолчание: http2_max_field_size 4k;
Контекст: http, server
Begrænser den maksimale størrelse af en anmodningsheader komprimeret ved hjælp af HPACK. Begrænsningen gælder både for navnet og værdien. Hvis der bruges Huffman-kodning, kan den faktiske størrelse af de udpakkede navne- og værdistrenge være større. Standardgrænsen er velegnet til de fleste forespørgsler.
Generelt er dette det. Og hvorfor alle? Fordi længden af linket var lang - længere end de samme 4k.
Ved at sætte den til f.eks. 8kb (eller så meget, som sandsynligvis er nok), løser vi problemet.
Sådan går det.
Kilde: www.habr.com