Un artigo da categoría de "notas".
TL: DR:
http2_max_field_size 8k; # всех спасет!Nun dos proxectos, despois de cambiar algunha lóxica interna do backend, comecei a observar nos rexistros un código_resposta estraño, é dicir, 0. Nos rexistros parece algo así:
{
"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 documentación e buscar en Google sobre este tema non deu absolutamente nada, porque... Indícase que este comportamento ocorre cando o cliente pechou a conexión sen pasar as cabeceiras. Ben, e varias cousas exóticas co tamaño do buffer para wsgi_, que no noso caso non encaixaba coa palabra "de ningún xeito".
En xeral, decidimos que o problema non é un problema, tendo en conta que nos nosos volumes non é para nada crítico.
Exactamente ata que quedei desconcertado co seguinte problema: nalgúns casos, as ligazóns ábrense sen problemas a través de http, pero néganse completamente a funcionar a través de https, producindo o marabilloso: a conexión #0 para host example.com deixou intacta
curl: (52) Resposta baleira do servidor
Nos rexistros, puidemos rastrexar esta cousa só por IP: non había ningunha solicitude nin ningún outro dato, como se pode ver no exemplo anterior. Só o estado notorio é 0, pero sei que non interrompín a solicitude! Comecei a descubrir que podía saír mal. E todo resultou moi sinxelo:
escoita 443 ssl http2 atraso=8192;
Ben, se usas http2 para conexións ssl, entón non abonda con configurar os búfers de solicitudes, tamén deben configurarse en ngx_http_v2_module, a saber:
Синтаксис: http2_max_field_size размер;
Умолчание: http2_max_field_size 4k;
Контекст: http, server
Limita o tamaño máximo dunha cabeceira de solicitude comprimida mediante HPACK. A restrición aplícase por igual tanto ao nome como ao valor. Se se utiliza a codificación Huffman, o tamaño real das cadeas de valores e nomes descomprimidos pode ser maior. O límite predeterminado é adecuado para a maioría das consultas.
En xeral, isto é. E por que todo? Porque a lonxitude da ligazón era longa, máis longa que eses mesmos 4k.
Ao configurar, por exemplo, 8 kb (ou tanto como é probable que sexa suficiente), resolvemos o problema.
Así vai.
Fonte: www.habr.com