[Nginx] Hur man besegrar response_status = 0

En artikel från kategorin "sidenoter".

TL: DR:

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

På ett av projekten, efter att ha ändrat lite intern logik i backend, började jag observera en konstig response_code i loggarna, nämligen 0. I loggarna ser det ut ungefär 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 detta ämne gav absolut ingenting - eftersom... Det anges att detta beteende uppstår när klienten stängde anslutningen utan att skicka rubrikerna. Jo, och diverse exotiska saker med buffertstorleken för wsgi_, som i vårt fall inte passade in på ordet "på något sätt".

I allmänhet bestämde vi oss för att problemet inte är ett problem, med hänsyn till det faktum att det i våra volymer inte alls är kritiskt.

Exakt tills jag blev förbryllad över följande problem: i vissa fall öppnas länkar utan problem via http, men vägrar helt att fungera via https, vilket ger det underbara: Anslutning #0 till värdexempel.com kvar intakt
curl: (52) Tomt svar från servern

I loggarna kunde vi spåra denna sak endast via IP - det fanns ingen begäran eller någon annan data, som kan ses från exemplet ovan. Endast den ökända statusen är 0, men jag vet att jag inte avbröt begäran! Jag började komma på vad som kunde gå fel. Och allt visade sig vara väldigt enkelt:

lyssna på 443 ssl http2 backlog=8192;

Tja, om du använder http2 för ssl-anslutningar räcker det inte bara att konfigurera förfrågningsbuffertarna, de måste också konfigureras i ngx_http_v2_module, nämligen:

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

Begränsar den maximala storleken på en begäranshuvud komprimerad med HPACK. Begränsningen gäller lika för både namnet och värdet. Om Huffman-kodning används kan den faktiska storleken på de uppackade namn- och värdesträngarna vara större. Standardgränsen är lämplig för de flesta frågor.

I allmänhet är detta det. Och varför alla? Eftersom längden på länken var lång - längre än samma 4k.

Genom att ställa in den på till exempel 8kb (eller så mycket som sannolikt räcker) löser vi problemet.
Sådana saker.

Källa: will.com

Lägg en kommentar