[Nginx] Hur övervinner man response_status = 0

Artikel av typen "anteckningar på marginalen."

TL:DR:

http2_max_field_size 8k; # räddar alla!

På ett av projekten, efter att ha ändrat en del intern logik i backend, började jag se en konstig response_code i loggarna, nämligen — 0. I loggarna ser det ungefär ut så här:

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

Att läsa dokumentationen och googla om ämnet gav mig ingenting — eftersom det påstås att sådant beteende uppstår när klienten har stängt anslutningen utan att skicka några rubriker. Och att det finns olika exotiska saker med bufferstorlekar för wsgi_, vilket i vårt fall var helt olämpligt.

I det stora hela beslutade vi att problemet — inte är ett problem, med tanke på att vid våra volymer är det helt ovidkommande.

Precis tills jag blev utmanad med nästa problem: i vissa fall öppnas länkar utan problem över http, men vägrar helt att fungera över https, vilket ger ett underbart: Connection #0 to host example.com left intact
curl: (52) Tomt svar från servern

I loggarna kunde man bara spåra detta genom IP — varken begäran eller någon annan information, som man kan se i exemplet ovan — finns. Endast den vansinniga statusen 0, men jag vet ju att jag inte avbröt begäran! Jag började gräva i vad som kunde gå fel. Och allt visade sig vara väldigt enkelt:

listen 443 ssl http2 backlog=8192;

Så, om man använder http2 för ssl-anslutningar, räcker det inte bara att konfigurera begärans buffertar, man måste också konfigurera dem i ngx_http_v2_module, nämligen:

Syntax:	http2_max_field_size storlek;
Standard:	http2_max_field_size 4k;
Kontext:	http, server

Begränsar den maximala storleken på en begärans rubrik, komprimerad med HPACK. Begränsningen gäller lika både namn och värde. Om Huffman-kodning används kan den faktiska storleken på de uppackade strängerna för namn och värde vara större. Standardbegränsningen passar de flesta begärningar.

Överlag, så är det. Och varför? För att längden på länken var stor — större än just de 4 k.

Genom att ställa in det på, till exempel, 8kb (eller så mycket som säkert behövs) – löser vi problemet.
Sådana är förhållandena.

Källa: habr.com