Caddy 2.11.6 durcit le reverse proxy par défaut et ajoute le matcher URLPattern
La 2.11.6 limite les en-têtes à 16 Ko, coupe les connexions en Slowloris et supprime les champs d’en-tête à point, au prix de changements cassants. Lisez les breaking changes avant de mettre à jour un serveur Caddy en production.
1er octobre 2026. Caddy publie la version 2.11.6, une release de maintenance qui embarque un durcissement de sécurité notable et un nouveau matcher de requêtes fondé sur le standard URLPattern. Juin 2026. La 2.11.4 avait déjà supprimé les champs d’en-tête contenant des tirets bas, et la 2.11.6 étend cette logique aux points. 1er octobre 2026. Le Go 1.26 devient la version minimale pour compiler Caddy et ses plugins. Pourquoi c’est important : le reverse proxy qui fait du HTTPS automatique change plusieurs comportements par défaut — limite d’en-têtes à 16 Kio, timeouts d’inactivité d’une minute, suppression des en-têtes à point — et il faut les lire avant de mettre à jour un serveur en production.
Le reverse proxy qui signe ses certificats tout seul
Caddy occupe une place précise dans le self-hosting : c’est le serveur web et reverse proxy qui obtient et renouvelle les certificats TLS automatiquement, via ACME, sans configuration manuelle ni certbot à part. Pour un homelab ou une petite équipe, il remplace l’assemblage Nginx + Let’s Encrypt par un seul binaire en Go, configuré dans un Caddyfile.
Cette simplicité a un revers : une bonne partie de la sécurité de Caddy repose sur des valeurs par défaut choisies par l’équipe. Quand ces défauts changent, comme dans la 2.11.6, le changement touche tous les serveurs qui n’ont jamais rien réglé — c’est-à-dire la majorité.
La release 2.11.6 est justement présentée par ses mainteneurs comme un durcissement, avec un avertissement explicite : « la plupart des changements cassants viennent du durcissement de sécurité, et la plupart des configurations ne s’en apercevront pas ». Mais celles qui s’appuyaient sur l’ancien comportement, elles, doivent le savoir.
Trois durcissements par défaut
Le premier changement est le plus visible : les en-têtes de requête sont limités à 16 Kio par défaut. Avant, Caddy utilisait le défaut de Go, soit 1 Mo. Une requête aux en-têtes trop volumineux — cookies géants, jetons surdimensionnés — reçoit désormais un 431 Request Header Fields Too Large. Le cas d’usage est rare en pratique, mais il existe : des applications qui mettent beaucoup d’état dans des cookies, ou des intégrations qui passent des jetons longs en en-tête. La parade documentée est l’option serveur max_header_size.
Le deuxième est une réponse directe au Slowloris, cette attaque qui ouvre des connexions et les laisse traîner en envoyant un octet de temps en temps. Caddy ajoute des timeouts d’inactivité d’une minute en lecture et en écriture : ils se réinitialisent à chaque lecture ou écriture réussie. Une connexion bloquée est coupée, une connexion lente mais qui progresse est laissée tranquille. Des taux de transfert minimaux optionnels complètent le dispositif, et une directive timeouts permet d’ajuster finement par route. Les pauses entre écritures — comme avec les Server-Sent Events — ne comptent pas.
Le troisième est le plus subtil : les champs d’en-tête contenant un point sont désormais supprimés, exactement comme les tirets bas l’avaient été en 2.11.4. La raison est documentée : PHP replie les points en tirets bas, ce qui permettait d’usurper des en-têtes légitimes. Les en-têtes à point nécessaires peuvent être autorisés explicitement via l’option serveur expected_dot_headers.
Un matcher qui parle le langage du navigateur
Côté fonctionnalités, la nouveauté la plus structurante est le matcher url_pattern. Il permet de filtrer les requêtes avec la syntaxe URLPattern, le standard du WHATWG déjà utilisé par les navigateurs et de nombreux frameworks web. Groupes nommés, jokers et composants regexp sont supportés, et les groupes capturés deviennent des placeholders {http.url_pattern.<composant>.<groupe>}, avec une fonction CEL url_pattern associée.
L’intérêt est d’aligner le langage de routage de Caddy sur celui que les développeurs connaissent déjà côté JavaScript. Un matcher qui ressemble à ce qu’on écrit dans un service worker ou un framework front réduit la friction entre le reverse proxy et l’application, et évite de réinventer une syntaxe de plus.
Deux options d’ergonomie complètent le lot. tls_automate_names gère les certificats de noms sans les servir dans un bloc de site — utile pour préparer un domaine avant de le brancher. Et expected_underscore_headers permet de conserver explicitement les en-têtes à tiret bas que la 2.11.4 avait supprimés, si une application en dépendait.
Reverse proxy, performances et streams
Le reverse proxy reçoit une série de corrections concrètes. Les réponses partielles sont désormais flusquées correctement vers les clients, le half-close TCP est propagé sur les flux upgradés, et les upstreams en versions 3 honorent l’option tls_trust_pool. L’état des health checks actifs est conservé séparément par configuration de check, si bien que les sondes en échec d’un handler ne marquent plus l’upstream comme mort pour tout le monde. La politique random_choose distribue correctement.
Les Server-Sent Events derrière la directive encode sont désormais streamés immédiatement au lieu d’être mis en tampon — un changement qui compte pour les applications temps réel derrière un proxy qui compresse. L’arrêt gracieux attend désormais les serveurs restés des configurations précédentes, pour ne pas couper les réponses longues démarrées avant un rechargement. Et le HTTP/3 fonctionne à travers Tailscale et les liens à faible MTU, grâce à une taille initiale de paquet QUIC réduite.
La performance progresse aussi : moins d’allocations dans les chemins chauds des requêtes, de la négociation d’encodage et du reverse proxy, et un directory browsing nettement plus rapide sur les gros répertoires.
Ce qu’il faut vérifier avant de mettre à jour
La liste des changements cassants est courte mais chacun peut mordre. Go 1.26 devient le minimum pour compiler Caddy et ses plugins — un point qui concerne surtout ceux qui buildent leurs propres images ou plugins. La limite d’en-têtes à 16 Kio et les timeouts d’inactivité d’une minute sont des changements de défaut qui peuvent couper des flux longs ou des clients aux en-têtes volumineux. La suppression des en-têtes à point peut casser une application qui en dépend.
Deux cas méritent une attention particulière. La première est la mTLS par héritage : le client_auth d’un site joker ne s’applique plus aux noms d’hôte plus spécifiques qui ont leur propre bloc de site. public.example.com n’hérite plus de la mTLS de *.example.com. La seconde est l’import dans les routes nommées : la directive import fonctionne désormais à l’intérieur des named routes, et les accolades citées sont traitées comme des arguments littéraux — de quoi modifier le comportement de configurations qui s’appuyaient sur l’ancienne limite.
La bonne pratique reste la même qu’à chaque montée de version : caddy validate sur la configuration, un test sur un environnement non critique, et une lecture attentive des changements cassants avant de toucher à la production.
Verdict
Si vous exécutez Caddy en production, cette release vaut la mise à jour pour le durcissement seul — la limite d’en-têtes et les timeouts anti-Slowloris referment des surfaces réelles — mais traitez-la comme une montée de version à vérifier, pas comme un simple patch : caddy validate, puis contrôlez max_header_size, expected_dot_headers et l’héritage client_auth si vous utilisez des jokers mTLS. Si vous êtes derrière Tailscale ou sur un lien à faible MTU, le correctif HTTP/3 est un argument de plus. Si vous buildez vos propres plugins, anticipez le passage à Go 1.26 avant de dépendre d’un binaire que vous ne pourrez plus compiler.