Egy cikk a „mellékjegyzetek” kategóriájából.
TL: DR:
http2_max_field_size 8k; # всех спасет!Az egyik projektnél a háttérrendszer belső logikájának megváltoztatása után furcsa válaszkódot kezdtem megfigyelni a naplókban, nevezetesen 0-t. A naplókban ez valahogy í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ó elolvasása és a témában való guglizás nem hozott semmit - mert... Ez a viselkedés akkor fordul elő, ha az ügyfél a fejlécek átadása nélkül zárta le a kapcsolatot. Nos, és különféle egzotikus dolgok wsgi_ puffermérettel, ami esetünkben nem illett a „semmilyen módon” szóhoz.
Általában úgy döntöttünk, hogy a probléma nem probléma, figyelembe véve azt a tényt, hogy a mi mennyiségünknél egyáltalán nem kritikus.
Egészen pontosan addig, amíg el nem ért a fejem a következő probléma előtt: bizonyos esetekben a linkek probléma nélkül megnyílnak a http-n keresztül, de teljesen megtagadják a https-en keresztüli működést, így a csodálatos: A 0. számú kapcsolat az example.com tárhellyel sértetlenül marad
curl: (52) Üres válasz a szervertől
A naplókban ezt a dolgot csak IP alapján tudtuk nyomon követni - se kérés, se egyéb adat nem volt, ahogy az a fenti példából is látszik. Csak a hírhedt állapot 0, de tudom, hogy nem szakítottam félbe a kérést! Elkezdtem kitalálni, hogy mi lehet a baj. És minden nagyon egyszerűnek bizonyult:
hallgatni 443 ssl http2 hátralék=8192;
Nos, ha a http2-t használod az ssl kapcsolatokhoz, akkor nem elég csak a kérési puffereket beállítani, azokat az ngx_http_v2_module-ban is be kell állítani, nevezetesen:
Синтаксис: http2_max_field_size размер;
Умолчание: http2_max_field_size 4k;
Контекст: http, server
Korlátozza a HPACK használatával tömörített kérésfejléc maximális méretét. A megszorítás a névre és az értékre egyaránt vonatkozik. Ha Huffman-kódolást használunk, a kicsomagolt név- és értékkarakterláncok tényleges mérete nagyobb lehet. Az alapértelmezett korlát a legtöbb lekérdezéshez megfelelő.
Általában ez az. És miért mind? Mivel a link hossza hosszú volt – hosszabb, mint ugyanez a 4k.
Ha például 8 kb-ra állítjuk (vagy annyit, amennyire valószínűleg elegendő), akkor megoldjuk a problémát.
Ilyen dolgok.
Forrás: will.com