[Nginx] Hoe responstatus = 0 te overwinnen

Een artikel van het type 'aantekeningen aan de rand'.

TL:DR:

http2_max_field_size 8k; # alles zal goedkomen!

Op een van de projecten begon ik een vreemd response_code in de logboeken te zien, namelijk — 0, na een wijziging in bepaalde interne logica van de backend. In de logboeken ziet het er ongeveer zo uit:

{
  "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": ""
}

Het lezen van de documentatie en googelen over dit onderwerp leverde helemaal niets op — omdat beweerd wordt dat dit gedrag optreedt wanneer de client de verbinding sluit zonder headers te verzenden. En allerlei exotica met de buffergrootte voor wsgi_, wat in ons geval totaal niet van toepassing was.

Over het algemeen hebben we besloten dat het probleem géén probleem is, gezien het feit dat het bij onze volumes helemaal niet kritisch is.

Juist tot het moment dat ik met het volgende probleem werd geconfronteerd: in sommige gevallen kunnen links probleemloos via http worden geopend, maar weigeren ze volledig om via https te werken, met de prachtige melding: Connection #0 to host example.com left intact
curl: (52) Leeg antwoord van de server

In de logboeken kon ik dit alleen volgen via IP — noch request, noch andere gegevens, zoals uit het bovenstaande voorbeeld blijkt — zijn beschikbaar. Alleen de beruchte status 0, maar ik weet dat ik de request niet heb afgebroken! Ik begon te graven wat er fout kon gaan. En het bleek heel eenvoudig:

listen 443 ssl http2 backlog=8192;

Nou, dus als http2 voor ssl-verbindingen wordt gebruikt, is het niet voldoende om alleen de aanvraagbuffers te configureren; deze moeten ook in ngx_http_v2_module worden geconfigureerd, namelijk:

Syntax:	http2_max_field_size size;
Standaard:	http2_max_field_size 4k;
Context:	http, server

Beperkt de maximale grootte van de aanvraagheader, gecomprimeerd met behulp van HPACK. De beperking is van toepassing op zowel de naam als de waarde. Als Huffman-codering wordt toegepast, kan de werkelijke grootte van de gedecomprimeerde naam- en waarde-strings groter zijn. De standaardlimiet is geschikt voor de meeste aanvragen.

In het algemeen is dit het. En waarom? Omdat de lengte van de link groot was — groter dan diezelfde 4k.

Door deze bijvoorbeeld in te stellen op 8kb (of zoveel als zeker voldoende is) — lossen we het probleem op.
Dat is het.

Bron: habr.com