Um artigo do tipo "notas à margem".
TL:DR:
http2_max_field_size 8k; # tudo será resolvido!Em um dos projetos, após alterar uma certa lógica interna do backend, comecei a observar um estranho response_code nos logs, especificamente — 0. Nos logs, aparece aproximadamente assim:
{
"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": ""
}
Ler a documentação e pesquisar sobre o assunto não trouxe resultado algum — pois afirma-se que esse comportamento ocorre quando o cliente fecha a conexão sem enviar os cabeçalhos. Além disso, houve uma variedade de problemas exóticos com o tamanho do buffer para wsgi_, que no nosso caso não se aplicava de forma alguma.
No geral, decidimos que o problema não era um problema, considerando que em nossos volumes isso não era crítico.
Exatamente até o momento em que fui confrontado com o seguinte problema: em alguns casos, os links abrem sem problemas via http, mas se recusam completamente a funcionar via https, gerando a linda mensagem: Connection #0 to host example.com left intact
curl: (52) Resposta vazia do servidor
Nos logs, consegui rastrear isso apenas por IP — nem requisição, nem outros dados, como pode ser visto no exemplo acima — estão presentes. Apenas o famoso status 0, mas eu sei que não interrompi a requisição! Comecei a investigar o que poderia dar errado. E tudo se revelou muito simples:
listen 443 ssl http2 backlog=8192;
Então, se você usar http2 para conexões ssl, não é suficiente apenas configurar os buffers da requisição; é necessário configurá-los também no ngx_http_v2_module, a saber:
Sintaxe: http2_max_field_size tamanho;
Padrão: http2_max_field_size 4k;
Contexto: http, server
Limita o tamanho máximo do cabeçalho da solicitação, que é compactado usando HPACK. A restrição se aplica igualmente tanto ao nome quanto ao valor. Se a codificação de Huffman é utilizada, o tamanho real das strings descompactadas do nome e do valor pode ser maior. A restrição padrão se adequa à maioria das solicitações.
Em resumo, é isso. E por que tudo isso? Porque o comprimento do link era grande — maior do que aqueles 4k.
Ao configurá-lo, por exemplo, para 8kb (ou quanto for necessário), resolvemos o problema.
Essas são as coisas.
Fonte: habr.com
