Caddy publicó v2.11.7, una versión parche que repara varios regresos funcionales detectados tras la actualización a 2.11.6 y que incorpora soporte para el nuevo encabezado Incremental definido en la RFC 10036. La actualización está recomendada para quienes ejecutan la 2.11.6, especialmente en entornos con proxys inversos y aplicaciones de streaming.
Qué cambia: correcciones clave
La versión 2.11.6 introdujo timeouts por defecto de lectura/escritura ociosos (idle read/write timeouts) que provocaron dos problemas principales corregidos en 2.11.7:
- Crash al proxyar sobre HTTP/2: en algunos casos el deadline (plazo) de inactividad del cuerpo de la petición podía seguir vigente después de que el handler hubiera terminado. Esto podía producir un panic por puntero nulo (nil pointer dereference) cuando el reverse proxy aún leía el cuerpo de la petición. La corrección evita ese estado inconsistente.
- Streams interrumpidos tras 60 segundos: en HTTP/1.1, respuestas en streaming sobre solicitudes con cuerpo (por ejemplo, clientes SSE que abren la conexión con POST) se cortaban exactamente al minuto una vez que el cuerpo había sido consumido. Ese comportamiento quedó resuelto para no truncar transmisiones legítimas.
- Resets de stream por pausas en HTTP/2: streams que pausaban entre escrituras por más tiempo que write_idle (1 minuto por defecto), como flujos SSE silenciosos, eran reiniciados con error de stream. La corrección hace que solo las escrituras que se estanquen cuenten como stall.
- Placeholders vacíos para cookies faltantes: desde la 2.11.6, placeholders no resueltos (por ejemplo {http.request.cookie.*} o {http.request.tls.*} en conexiones HTTP simples) podían mostrarse literalmente en respuesta. Ahora esos placeholders se dejan vacíos cuando la cookie o el dato TLS no existen.
Nuevo soporte: encabezado Incremental (RFC 10036)
La versión añade soporte para el encabezado Incremental, que nace como reemplazo estándar de la cabecera propietaria X-Accel-Buffering de NGINX. Cuando una respuesta upstream incluye Incremental: ?1, reverse_proxy la reenvía inmediatamente y trata el stream como encodable/fluido (equivalente a un flush_interval a -1). Esto beneficia aplicaciones de streaming como Mercure o SSE, donde la entrega inmediata de fragmentos es necesaria para la latencia baja.
Otras mejoras operativas
- Manos más rápidas en TLS: CertMagic dejó de construir datos de evento para cada handshake cuando no hay suscriptores y el logging de debug está desactivado; la búsqueda de certificados por handshake es ahora más veloz y con menos asignaciones en memoria.
- Unix sockets al recargar: si un reload mueve un listener (o el endpoint admin) fuera de un socket Unix, el socket antiguo se cierra y su archivo se elimina de inmediato, evitando que clientes que intenten conectar queden colgados durante minutos.
- Cabeceras Set-Cookie desde JSON: múltiples valores Set-Cookie declarados en un conjunto JSON se envían ahora como campos de cabecera separados en lugar de concatenarse con comas, lo que mejora la compatibilidad con clientes.
- Correcciones menores: ajustes en el formateador caddy fmt para no borrar una llave de apertura al final del input, entre otros arreglos menores.
Qué debe hacer el administrador
Si su infraestructura usa Caddy 2.11.6, actualice a 2.11.7 para evitar los crashes y cortes de streams descritos, especialmente si emplea reverse_proxy con HTTP/2 o aplicaciones que usan SSE y otros flujos en tiempo real. Además, revise configuraciones que dependan de comportamiento de buffering: la compatibilidad con el encabezado Incremental permite gestionar el comportamiento de buffering upstream de forma estándar.
Tras la actualización conviene probar escenarios de streaming (SSE, Mercure, proxys que pasen cuerpos largos) y comprobar logs de TLS si la aplicación es sensible a latencias de handshake. No se requieren cambios de configuración obligatorios para las correcciones de timeout, pero activar pruebas de integración con tráfico real ayudará a validar el comportamiento en producción.
Lee también:
- Traefik lanza v3.7.13: múltiples correcciones y cinco avisos de seguridad resueltos
- CloudLinux ELevate permite ahora actualizar in-place de CloudLinux 8 a 9 en servidores con Plesk
Fuente: Release notes from caddy
