En artikel fra kategorien "noter i margenen".
TL: DR:
http2_max_field_size 8k; # всех спасет!På et af projekterne, efter at have ændret noget intern logik i backend'en, begyndte jeg at observere en mærkelig response_code i loggene, nemlig -0. I loggene ser det nogenlunde 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 ingenting - da det hævdes, at en sådan opførsel opstår, når klienten lukker forbindelsen uden at sende headerne. Nå, og diverse eksotiske ting med bufferstørrelsen for wsgi_, hvilket i vores tilfælde slet ikke var passende.
Samlet set besluttede vi, at problemet ikke er et problem, da det med vores mængder slet ikke er kritisk.
Indtil det øjeblik, hvor jeg var forvirret over følgende problem: i nogle tilfælde åbner links uden problemer via http, men nægter fuldstændigt at virke via https, hvilket giver det vidunderlige: Forbindelse #0 til værten example.com forbliver intakt.
curl: (52) Tomt svar fra serveren
I loggene kunne jeg kun spore denne ting via IP - ingen anmodning, ingen andre data, som du kan se i eksemplet ovenfor. Kun den berygtede status 0, men jeg ved, at jeg ikke afbrød anmodningen! Jeg begyndte at grave rundt, hvad der kunne gå galt. Og alt viste sig at være meget simpelt:
lyt 443 ssl http2 efterslæb=8192;
Hvis du bruger http2 til SSL-forbindelser, er det ikke nok blot at konfigurere request buffers, du skal også konfigurere dem 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 med HPACK. Grænsen gælder ligeligt for både navn og værdi. Hvis Huffman-kodning bruges, kan den faktiske størrelse af de dekomprimerede navne- og værdistrenge være større. Standardgrænsen er egnet til de fleste anmodninger.
Nå, det var det. Og hvorfor? Fordi linklængden var lang - længere end de 4k.
Ved at indstille den til for eksempel 8 kb (eller så meget som sandsynligvis vil være nok), løser vi problemet.
Sådanne ting.
Kilde: www.habr.com
