[Nginx] Kiel venki response_status = 0

Artikolo el la kategorio "flankaj notoj".

TL: DR:

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

Sur unu el la projektoj, post ŝanĝi ian internan logikon de la backend, mi komencis observi strangan respond_kodon en la protokoloj, nome 0. En la protokoloj ĝi aspektas kiel ĉi tio:

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


Legado de la dokumentaro kaj guglo pri ĉi tiu temo donis absolute nenion - ĉar... Estas deklarite, ke ĉi tiu konduto okazas kiam la kliento fermis la konekton sen pasi la kapliniojn. Nu, kaj diversaj ekzotaj aferoj kun la bufrograndeco por wsgi_, kiu en nia kazo ne kongruis kun la vorto "iel".

Ĝenerale, ni decidis, ke la problemo ne estas problemo, konsiderante la fakton, ke ĉe niaj volumoj ĝi tute ne estas kritika.

Ĝuste ĝis mi estis konfuzita de la sekva problemo: en kelkaj kazoj, ligiloj malfermiĝas senprobleme per http, sed tute rifuzas labori per https, produktante la mirindan: Konekto #0 por gastigi example.com lasita sendifekta
buklo: (52) Malplena respondo de servilo

En la protokoloj, ni povis spuri ĉi tiun aferon nur per IP - ne estis peto aŭ ajna alia datumo, kiel videblas el la supra ekzemplo. Nur la fifama stato estas 0, sed mi scias, ke mi ne interrompis la peton! Mi komencis eltrovi kio povus misfunkcii. Kaj ĉio montriĝis tre simpla:

aŭskultu 443 ssl http2 restarigo=8192;

Nu, se vi uzas http2 por ssl-konektoj, tiam ne sufiĉas nur agordi la petajn bufrojn, ili ankaŭ devas esti agorditaj en ngx_http_v2_module, nome:

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

Limigas la maksimuman grandecon de peta kaplinio kunpremita per HPACK. La limo validas egale al kaj la nomo kaj la valoro. Se Huffman-kodigo estas uzata, la reala grandeco de la malpakitaj nomo kaj valorĉenoj povas esti pli granda. La defaŭlta limo taŭgas por plej multaj demandoj.

Ĝenerale, ĉi tio estas. Kaj kial ĉio? Ĉar la longo de la ligo estis longa - pli longa ol tiuj samaj 4k.

Agordante ĝin al, ekzemple, 8kb (aŭ tiom multe kiom verŝajne sufiĉas), ni solvas la problemon.
Do ĝi iras.

fonto: www.habr.com

Aldoni komenton