[Nginx] Как да победим response_status = 0

Статия от категорията „странични бележки“.

TL: DR:

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

В един от проектите, след като промених някаква вътрешна логика на бекенда, започнах да наблюдавам странен response_code в регистрационните файлове, а именно 0. В регистрационните файлове изглежда нещо подобно:

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

Четенето на документацията и гугълането по тази тема не даде абсолютно нищо - защото... Посочено е, че това поведение възниква, когато клиентът затвори връзката, без да премине заглавките. Е, и различни екзотични неща с размера на буфера за wsgi_, който в нашия случай не отговаряше на думата „по никакъв начин“.

Като цяло решихме, че проблемът не е проблем, като се има предвид, че при нашите обеми той изобщо не е критичен.

Точно докато не бях озадачен от следния проблем: в някои случаи връзките се отварят без проблеми през http, но напълно отказват да работят през https, създавайки прекрасното: Връзка #0 към хост example.com остава непокътната
curl: (52) Празен отговор от сървъра

В логовете успяхме да проследим това нещо само по IP - нямаше заявка или други данни, както се вижда от горния пример. Само прословутият статус е 0, но знам, че не съм прекъснал заявката! Започнах да разбирам какво може да се обърка. И всичко се оказа много просто:

слушайте 443 SSL http2 изоставане=8192;

Е, ако използвате http2 за ssl връзки, тогава не е достатъчно само да конфигурирате буферите на заявките, те също трябва да бъдат конфигурирани в ngx_http_v2_module, а именно:

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

Ограничава максималния размер на заглавката на заявка, компресирана с помощта на HPACK. Ограничението важи еднакво както за името, така и за стойността. Ако се използва кодиране на Huffman, действителният размер на разопакованите низове за име и стойност може да е по-голям. Ограничението по подразбиране е подходящо за повечето заявки.

В общи линии това е. И защо всички? Защото дължината на връзката беше дълга - по-голяма от същите тези 4k.

Като го настроим например на 8kb (или колкото е възможно да е достатъчно), решаваме проблема.
Такива случаи.

Източник: www.habr.com