[Nginx] Cómo vencer la respuesta_status = 0

Un artículo de la categoría de “notas al margen”.

TL: DR:

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

En uno de los proyectos, después de cambiar alguna lógica interna del backend, comencé a observar un código de respuesta extraño en los registros, concretamente 0. En los registros se ve 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": ""
}


Leer la documentación y buscar en Google sobre este tema no arrojó absolutamente nada, porque... Se afirma que este comportamiento ocurre cuando el cliente cierra la conexión sin pasar los encabezados. Bueno, y varias cosas exóticas con el tamaño del búfer para wsgi_, que en nuestro caso no se ajustaba a la palabra "de ninguna manera".

En general, decidimos que el problema no es un problema, teniendo en cuenta que en nuestros volúmenes no es nada crítico.

Exactamente hasta que me desconcertó el siguiente problema: en algunos casos, los enlaces se abren sin problemas a través de http, pero se niegan completamente a funcionar a través de https, lo que produce lo maravilloso: La conexión #0 al host example.com queda intacta
curl: (52) Respuesta vacía del servidor

En los registros, pudimos rastrear esto solo por IP; no hubo ninguna solicitud ni ningún otro dato, como se puede ver en el ejemplo anterior. ¡Solo el notorio estado es 0, pero sé que no interrumpí la solicitud! Empecé a descubrir qué podría salir mal. Y todo resultó muy sencillo:

escucha 443 ssl http2 trabajo pendiente=8192;

Bueno, si usa http2 para conexiones SSL, entonces no basta con configurar los buffers de solicitud, también deben configurarse en ngx_http_v2_module, a saber:

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

Limita el tamaño máximo de un encabezado de solicitud comprimido mediante HPACK. La restricción se aplica igualmente tanto al nombre como al valor. Si se utiliza la codificación Huffman, el tamaño real de las cadenas de nombre y valor descomprimidas puede ser mayor. El límite predeterminado es adecuado para la mayoría de las consultas.

En general, esto es todo. ¿Y por qué todos? Porque la longitud del enlace era larga, más larga que esos mismos 4k.

Configurándolo, por ejemplo, en 8kb (o tanto como sea suficiente), solucionamos el problema.
Tales casos.

Fuente: habr.com

Añadir un comentario