Статья из разряда «заметки на полях».
На одном из проектов, после изменения некоторой внутренней логики бекенда, начал наблюдать странный response_code в логах, а именно — 0. В логах выглядит примерно так:
Чтение документации и гугление на данную тему дало ровным счетом ничего — т.к. утверждается, что такое поведение возникает, когда клиент закрыл соединение не передав заголовки. Ну и разная экзотика с размером буффера для wsgi_, что в нашем случае не подходило от слова «никак».
В целом, решили, что проблема — не проблема, с учетом того, что на наших объемах оно совершенно не критично.
Ровно до того момента, пока меня не озадачили следующей проблемой: в некоторых случаях ссылки без проблем открываются по http, но совершенно отказываются работать по https, выдавая чудесное: Connection #0 to host example.com left intact
curl: (52) Empty reply from server
В логах отследить эту штуку удалось только по IP — ни реквеста, ни каких-либо других данных, как видно из примера выше — нет. Только пресловутый статус 0, но я-то знаю, что запрос я не прерывал! Начал ковырять, что же может пойти не так. А все оказалось очень просто:
listen 443 ssl http2 backlog=8192;
Ну так вот — если использовать http2 для ssl-соединений, то недостаточно просто конфигурять буферы запроса, конфигурять их надо и в ngx_http_v2_module, а именно:
Ограничивает максимальный размер заголовка запроса, сжатого при помощи HPACK. Ограничение применяется в равной степени как к имени, так и к значению. Если применяется кодирование Хаффмана, то фактический размер распакованных строк имени и значения может быть больше. Ограничение по умолчанию подходит для большинства запросов.
В общем, это оно. А все почему? Потому что длина ссылки была большой — больше, чем те самые 4k.
Выставив его в, например, 8kb (или столько, сколько наверняка хватит) — решаем проблему.
Такие дела.
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, выдавая чудесное: Connection #0 to host example.com left intact
curl: (52) Empty reply from server
В логах отследить эту штуку удалось только по 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 (или столько, сколько наверняка хватит) — решаем проблему.
Такие дела.
shepardeg
Недавно в группе NGINX_RU телеграмма или DevOPS обсуждали и решили эту проблему тоже.
Porfel Автор
Жаль, что телеграм-каналы и прочие групповые чаты не индексируются поисковиками. Тогда бы я у себя это решил месяца полтора бы назад, а не когда сегодня ко мне прибежали с «ааааа!!! https не работает» =) На самом деле, каналы — это, конечно, хорошо, но тот поток флуда, который там, как правило, есть — очень нервирует. Особенно, когда следуешь правилу «чистого инбокса». Но за наводку спасибо — мб даже подпишусь.