[Nginx] Hvordan beseire response_status = 0

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

Legg til en kommentar