- Se descapó
- 20 de agosto de 2026 a las 22:52 UTC
- Autor
- Kamo
- Compromit
- 584b84a
Dos cosas, una de ellas una corrección a la comisión anterior a esto. El anterior cometido justificó las "codificaciones": [br, gzip] con una sonda contra api.kamocrm.com. Esa sonda estaba equivocada. Conjuntos APIService "server.compression.enabled: true* en su ConfigMap - nota su repo application.yml dice falso, el ConfigMap es lo que se ejecuta, por lo que el origen Ya había volcado y Traefik estaba pasando el cuerpo intacto. Cada número en ese comentario fue de Spring, atribuido a Traefik. El comentar ahora lo dice explícitamente, porque el error es fácil de repetir: casi todos los orígenes detrás de esa cadena se auto-comprimen, así que sondearlos muestra gzip y se parece a Traefik eligiendo gzip. El reclamo en sí sobrevive, medido adecuadamente. El anfitrión temático es el que lugar Traefik es siempre el compresor, porque MinIO sirve almacenado bytes y no negocia nada. En el paquete de chat widget, 145.587 bytes en la medida en que se almacenan: Accept-Encoding: gzip - . gzip 45,501 Accept-Encoding: br, gzip - . gzip 45,501 Accept-Encoding: gzip, deflate, br, zstd -o gzip 45,501 Acepta-Encoding: br -' br 40,754 Aceptar-Encoding: * - none 145,587 La segunda línea es el hallazgo: brotli solicitado FIRST todavía devuelve gzip. Traefik ignora el pedido del cliente y toma gzip cada vez que es aceptable, por lo que ningún navegador ha recibido la codificación más pequeña. La última línea es un segundo defecto sin "encodings" set hay Nada para que un comodín se resuelva, así que no tiene compresión en absoluto. Eso es el 10,4% de un paquete que carga en los propios sitios de los clientes, así que La compresión de temas obtiene las mismas codificaciones y mínimas que las compartidas middleware. minResponseBodyBytes está documentado como un clavado por defecto en lugar de comportamiento cambiante: 1024 ya es el default de Traefik, confirmado por la 483-byte widget cargador pasando descomprimido sin ajuste. Verificado en directo después del despliegue anterior: el middleware lleva (así que la actualización de CRD v3.3 hizo su trabajo y el campo no era podado), un "Accept-Encoding": *o request returns br, y el PNG que Solía volver 30 bytes más grande de lo que la fuente ahora está intacta.