[Nginx] Cum să învinge response_status = 0

Un articol din categoria „note secundare”.

TL: DR:

http2_max_field_size 8k; # всех спасет!

Pe unul dintre proiecte, după ce am schimbat o logică internă a backend-ului, am început să observ un răspuns_cod ciudat în jurnale, și anume 0. În jurnale arată cam așa:

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


Citirea documentației și căutarea pe google pe acest subiect nu au dat absolut nimic - pentru că... Se afirmă că acest comportament apare atunci când clientul a închis conexiunea fără a trece anteturile. Ei bine, și diverse lucruri exotice cu dimensiunea tamponului pentru wsgi_, care în cazul nostru nu se potrivea cu cuvântul „în niciun fel”.

În general, am decis că problema nu este o problemă, ținând cont de faptul că la volumele noastre nu este deloc critică.

Exact până când am fost nedumerit de următoarea problemă: în unele cazuri, link-urile se deschid fără probleme prin http, dar refuză complet să funcționeze prin https, producând minunatul: Conexiune #0 pentru a găzdui example.com rămas intactă
curl: (52) Răspuns gol de la server

În jurnale, am putut urmări acest lucru numai prin IP - nu a existat nicio solicitare sau alte date, așa cum se poate vedea din exemplul de mai sus. Doar starea notorie este 0, dar stiu ca nu am intrerupt cererea! Am început să-mi dau seama ce ar putea merge prost. Și totul s-a dovedit a fi foarte simplu:

asculta 443 ssl http2 întârziere=8192;

Ei bine, dacă utilizați http2 pentru conexiuni ssl, atunci nu este suficient doar să configurați bufferele de solicitare, acestea trebuie configurate și în ngx_http_v2_module și anume:

Синтаксис:	http2_max_field_size размер;
Умолчание:	http2_max_field_size 4k;
Контекст:	http, server

Limitează dimensiunea maximă a unui antet de cerere comprimat folosind HPACK. Constrângerea se aplică în mod egal atât numelui, cât și valorii. Dacă se utilizează codificarea Huffman, dimensiunea reală a șirurilor de nume și valori despachetate poate fi mai mare. Limita implicită este potrivită pentru majoritatea interogărilor.

În general, asta este. Și de ce toate? Pentru că lungimea legăturii era lungă - mai mare decât aceleași 4k.

Setându-l la, de exemplu, 8 kb (sau cât este probabil suficient), rezolvăm problema.
Asemenea lucruri.

Sursa: www.habr.com

Adauga un comentariu