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

Статия от типа „записки на полях“.

Кратко:

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, издавайки чудесното: Connection #0 to host example.com left intact
curl: (52) Празен отговор от сървъра

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

listen 443 ssl http2 backlog=8192;

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

Синтаксис:	http2_max_field_size размер;
По подразбиране:	http2_max_field_size 4k;
Контекст:	http, server

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

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

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

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

Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри 🔥 Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри | ProHoster