En artikkel fra kategorien "sidenoter".
TL: DR:
http2_max_field_size 8k; # всех спасет!
På et av prosjektene, etter å ha endret litt intern logikk i backend, begynte jeg å observere en merkelig response_code i loggene, nemlig 0. I loggene ser det 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 om dette emnet ga absolutt ingenting - fordi... Det er oppgitt at denne oppførselen oppstår når klienten lukket forbindelsen uten å sende overskriftene. Vel, og diverse eksotiske ting med bufferstørrelsen for wsgi_, som i vårt tilfelle ikke passet til ordet "på noen måte".
Generelt bestemte vi oss for at problemet ikke er et problem, tatt i betraktning at på våre volumer er det ikke i det hele tatt kritisk.
Nøyaktig inntil jeg ble forundret over følgende problem: i noen tilfeller åpnes lenker uten problemer via http, men nekter fullstendig å fungere via https, og produserer den fantastiske: Forbindelse #0 til host example.com forble intakt
curl: (52) Tomt svar fra server
I loggene kunne vi spore denne tingen kun ved hjelp av IP - det var ingen forespørsel eller andre data, som kan sees fra eksempelet ovenfor. Bare den beryktede statusen er 0, men jeg vet at jeg ikke avbrøt forespørselen! Jeg begynte å finne ut hva som kunne gå galt. Og alt viste seg å være veldig enkelt:
hør 443 ssl http2 backlog=8192;
Vel, hvis du bruker http2 for ssl-tilkoblinger, er det ikke nok bare å konfigurere forespørselsbufferne, de må også konfigureres 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ørselshode komprimert med HPACK. Begrensningen gjelder både for navnet og verdien. Hvis Huffman-koding brukes, kan den faktiske størrelsen på de utpakkede navn- og verdistrengene være større. Standardgrensen passer for de fleste søk.
Generelt er dette det. Og hvorfor alle? Fordi lengden på lenken var lang - lengre enn de samme 4k.
Ved å sette den til for eksempel 8kb (eller så mye som sannsynligvis er nok), løser vi problemet.
Så det går.
Kilde: www.habr.com