[Nginx] Jak pokonać status_odpowiedzi = 0

Artykuł z kategorii „sidenotes”.

TL: DR:

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

Na jednym z projektów po zmianie jakiejś wewnętrznej logiki backendu zacząłem obserwować w logach dziwny kod_odpowiedzi, a mianowicie 0. W logach wygląda to mniej więcej tak:

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


Czytanie dokumentacji i googlowanie na ten temat nie przyniosło absolutnie nic - ponieważ ... Stwierdzono, że takie zachowanie występuje, gdy klient zamyka połączenie bez przekazywania nagłówków. No i różne egzotyczne rzeczy z wielkością bufora dla wsgi_, która w naszym przypadku nie pasowała do słowa „w żaden sposób”.

Ogólnie zdecydowaliśmy, że problem nie stanowi problemu, biorąc pod uwagę fakt, że przy naszych wolumenach nie jest to wcale krytyczne.

Dokładnie do czasu, gdy zaintrygował mnie następujący problem: w niektórych przypadkach linki otwierają się bez problemów przez http, ale całkowicie odmawiają działania przez https, tworząc wspaniałe: Połączenie nr 0 z hostem example.com pozostawione nienaruszone
curl: (52) Pusta odpowiedź z serwera

W logach udało nam się to namierzyć jedynie po adresie IP - nie było żadnego żądania ani żadnych innych danych, co widać na powyższym przykładzie. Tylko notoryczny status to 0, ale wiem, że nie przerwałem żądania! Zacząłem zastanawiać się, co może pójść nie tak. I wszystko okazało się bardzo proste:

słuchaj 443 ssl http2 zaległości=8192;

Cóż, jeśli używasz protokołu http2 do połączeń ssl, to nie wystarczy samo skonfigurowanie buforów żądań, należy je również skonfigurować w ngx_http_v2_module, a mianowicie:

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

Ogranicza maksymalny rozmiar nagłówka żądania skompresowanego przy użyciu HPACK. Ograniczenie dotyczy w równym stopniu zarówno nazwy, jak i wartości. Jeśli używane jest kodowanie Huffmana, rzeczywisty rozmiar rozpakowanych ciągów nazw i wartości może być większy. Domyślny limit jest odpowiedni dla większości zapytań.

Ogólnie rzecz biorąc, to jest to. I dlaczego wszystko? Bo długość linku była długa - dłuższa niż te same 4k.

Ustawiając go na przykład na 8kb (lub tyle, ile prawdopodobnie wystarczy), rozwiązujemy problem.
Takie rzeczy

Źródło: www.habr.com

Dodaj komentarz