A cikk a „mellékjegyzetek” kategóriájába tartozik.
TL:DR:
http2_max_field_size 8k; # mindenki meg fog menteni!Egyik projektünk során, miután módosítottuk a backend néhány belső logikáját, furcsa response_code-ot kezdtem észlelni a naplóban, nevezetesen — 0-t. A naplóban körülbelül így néz ki:
{
"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": ""
}
A dokumentáció olvasása és a téma körüli googlizás nem hozott semmit — mivel állítólag ez a viselkedés akkor fordul elő, amikor a kliens a fejlécek továbbítása nélkül zárja be a kapcsolatot. És különféle egzotikumok a wsgi_ puffer méretével kapcsolatban, ami esetünkben szintén egyáltalán nem volt megfelelő.
Összességében úgy döntöttünk, hogy a probléma — nem probléma, figyelembe véve, hogy a mi volumeneink mellett ez egyáltalán nem kritikus.
Pont addig a pillanatig, amíg nem szembesültem a következő problémával: bizonyos esetekben a linkek problémamentesen nyílnak meg http-n, de teljesen elutasítják a működést https-en, csodás üzenetet adva: Connection #0 to host example.com left intact
curl: (52) Üres válasz a szervertől
A naplókban ezt csak IP alapján sikerült nyomon követni — se kérést, se egyéb adatokat, ahogy az fentebbi példából is látszik — nincs. Csak a híres 0-ás státusz, de tudom, hogy a kérés nem szakadt meg! Elkezdtem kutakodni, hogy mi mehetett el rosszul. És minden nagyon egyszerűen alakult:
listen 443 ssl http2 backlog=8192;
Szóval — ha http2-t használunk ssl-kapcsolatokhoz, akkor nem elég csak a kérés puffereit konfigurálni, hanem azokat is be kell állítani az ngx_http_v2_module-ban, nevezetesen:
Szintaxis: http2_max_field_size méret;
Alapértelmezés: http2_max_field_size 4k;
Kontekstus: http, server
Korlátozza a HPACK segítségével tömörített kérés fejlécének maximális méretét. A korlátozás egyaránt vonatkozik a névre és az értékre. Ha Huffman kódolást alkalmazunk, akkor az észlelhető kibővített név és érték tényleges mérete nagyobb lehet. Az alapérték a legtöbb kérelemhez megfelelő.
Szóval, ez az. És miért? Mert a hivatkozás hossza nagy volt — nagyobb, mint a bizonyos 4k.
Ha például 8kb-ra állítjuk (vagy annyira, amennyi biztosan elég lesz) — megoldjuk a problémát.
Ezek a dolgok.
Forrás: habr.com
