miércoles, 18 de marzo de 2020

NGINX: net::ERR_HTTP2_PROTOCOL_ERROR



Cómo solucionar el error net::ERR_HTTP2_PROTOCOL_ERROR en NGINX y Google Chrome.



Recientemente, me tocó publicar una aplicación web en internet que corría sobre un servidor web WildFly. Para ello, usé NGINX como reverse proxy para enrutar las peticiones de entrada al servidor web.

Desde Firefox, IE y Edge, la web era accesible sin problemas, pero al acceder desde Chrome e ir a un apartado concreto, la web se quedaba cargando indefinidamente.

Tras debugar con las herramientas de desarrollador de Chrome, llegué al siguiente error:


net::ERR_HTTP2_PROTOCOL_ERROR 200

Trasteando con los logs de nginx vi que el problema residía en que el backend, es decir, el servidor al que pasaba las peticiones el NGINX, tenía activada la compresión gzip en el envío de cabeceras. NGINX, por su parte, comprimía de nuevo las cabeceras de cada petición. Y Chrome, en el extremo final, no es capaz de procesar esa doble compresión.

Por lo visto, Chome no es capaz de procesar cabeceras doblemente comprimidas y cuando le llegan ese tipo de cabeceras muestra el "descriptivo" error "HTTP2_PROTOCOL_ERROR".

Para evitar que haya una doble compresión de cabeceras al usar NGINX como proxy inverso, debemos insertar la siguiente línea en el apartado location del bloque server de ese dominio:

proxy_set_header Accept-Encoding "";

Esta directriz le indica a NGINX que edite la cabecera que se enviará al servidor que está detrás del proxy para que este no comprima sus respuestas. De esta manera, se recibirán respuestas sin comprimir por parte del backend, que Chrome podrá tratar sin problema.

El bloque entero debería parecerse a esto:

server { ... location / { ... proxy_set_header Accept-Encoding ""; ... } }

Una vez aplicada esta configuración, recargué NGINX.

A partir de este momento, la web funcionó correctamente bajo Google Chrome.

Otra posibilidad hubiera sido desactivar la compresión en el backend, pero yo no tenía acceso administrativo al servidor. En mi caso, solo podía jugar con la configuración del proxy inverso.


Fuentes:

https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/
https://www.busindre.com/uso_de_sub_filter_en_nginx_como_proxy_reverso
0

0 comentarios:

Publicar un comentario