En artikkel fra kategorien «notater i margen».
TL: DR:
http2_max_field_size 8k; # всех спасет!På et av prosjektene, etter å ha endret noe intern backend-logikk, begynte jeg å se en merkelig response_code i loggene – nærmere bestemt 0. Loggene så omtrent slik ut:
{
"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": ""
}
Å lese dokumentasjonen og google emnet ga absolutt ingenting, ettersom det hevdes at denne oppførselen oppstår når klienten lukker forbindelsen uten å overføre headerne. Og det er også noen eksotiske ting om bufferstørrelsen for wsgi_, som i vårt tilfelle var fullstendig uegnet.
Alt i alt konkluderte vi med at problemet ikke var et problem, gitt at det med våre volumer slett ikke var kritisk.
Helt til det øyeblikket jeg ble forvirret av følgende problem: i noen tilfeller åpnes lenker uten problemer over http, men nekter fullstendig å fungere over https, noe som gir det fantastiske: Forbindelse #0 til verten example.com forblir intakt
curl: (52) Tomt svar fra serveren
Jeg klarte bare å spore dette opp i loggene via IP-adresse – ingen forespørsel eller andre data, som du kan se i eksemplet ovenfor. Bare den beryktede statusen 0, men jeg vet at jeg ikke avbrøt forespørselen! Jeg begynte å grave rundt for å se hva som kunne være galt. Det viste seg å være veldig enkelt:
lytt 443 ssl http2 etterslep=8192;
Vel, hvis du bruker http2 for SSL-tilkoblinger, er det ikke nok å bare konfigurere forespørselsbuffere; du må også konfigurere dem i ngx_http_v2_module, nemlig:
Синтаксис: http2_max_field_size размер;
Умолчание: http2_max_field_size 4k;
Контекст: http, server
Begrenser den maksimale størrelsen på en forespørselsheader komprimert med HPACK. Denne grensen gjelder både for navn og verdi. Hvis Huffman-koding brukes, kan den faktiske størrelsen på de dekomprimerte navn- og verdistrengene være større. Standardgrensen er egnet for de fleste forespørsler.
Så, det var det. Men hvorfor? Fordi lenkelengden var lang – lengre enn de 4k.
Ved å sette den til for eksempel 8 kb (eller så mye som sannsynlig er nok), løser vi problemet.
Så det går.
Kilde: www.habr.com
