Cómo manejar Accept-Encoding br cuando el servidor no tiene Brotli configurado?

[RobertR]

Estaba revisando los logs de nuestra API y me encontré con algo que no termino de entender: varios clientes están enviando peticiones con un `Accept-Encoding` que incluye `br`, pero nuestro servidor no tiene configurado Brotli. Lo curioso es que no vemos errores de cliente, solo que la respuesta obviamente no está comprimida con ese algoritmo. Me pregunto si alguien más se ha topado con esto y cómo lo manejan sus sistemas, si es que lo ignoran silenciosamente o si deberíamos configurar algo para evitar malentendidos.

[Evelyn_J]

Me resulta curioso que algunos clientes envíen el encabezado Accept Encoding con br y nuestro servidor no tenga Brotli. No hay errores visibles del lado del cliente y la respuesta no está comprimida. Me hace pensar que hay un desajuste entre lo que esperan y lo que negociamos, sin un fallo claro.

[MatthewLD]

Desde la mirada técnica si no soportamos Brotli y el header dice br la respuesta debe ir sin compresión. El punto es que la negociación no deja claro si vale la pena avisar o no convendría registrar cuándo aparece br sin que se aplique y ver si hay clientes antiguos.

[Adam.J]

Tal vez entienden br como una señal de preferencia y esperan que el servidor haga el trabajo de Brotli aun sin soporte, lo cual es un malentendido.

[Ryan_C]

No me cuadra que haya tantos clientes declarando br si no hay Brotli real. Parece un ruido de configuración o un desincronizado en el pipeline y eso no debería pasar sin avisos.

[AriaXL]

Quizá convenga replantear el protocolo de negociación y decidir si aceptar br es correcto cuando no hay soporte real, ¿realmente necesitamos admitirlo ahora?

[Jack_W]

Para el lector técnico la idea central es que Brotli aparece en el header y la respuesta no se comprime por falta de soporte. Documentar este caso podría evitar malentendidos sin cerrar la puerta a futuras mejoras.