Merci, je n’avais pas vu cette PR. C’est intéressant – ma configuration est légèrement différente car j’ai conservé le serveur web nginx de Discourse et fait fonctionner Caddy séparément dans Docker Compose devant, principalement pour fournir HTTP/3 au niveau du périmètre.
Il y a un petit changement côté Discourse : j’ai ajouté un hook persistant dans app.yml afin que nginx utilise la valeur X-Forwarded-For de Caddy pour l’adresse IP réelle du client lorsque les requêtes arrivent via le socket Unix. J’avais initialement besoin d’une solution de contournement avec X-Real-IP dans Caddy, mais après avoir ajouté la correction côté nginx, j’ai pu la supprimer et vérifier que Discourse enregistrait toujours la bonne adresse IP du client.
J’ai également explicitement désactivé QUIC 0-RTT/les données anticipées dans la configuration de Caddy tout en laissant HTTP/3 activé, afin d’éviter ce cas limite supplémentaire lié aux données anticipées.
Mon approche permet également d’activer la journalisation des accès HTTP de Caddy au niveau du site, ce qui me donne la suppression automatique par défaut des en-têtes de credentials sensibles par Caddy. Je fais la rotation des journaux Docker json-file résultants à 25 Mo × 3. J’ai remarqué que la PR actuelle place son bloc de rotation des journaux dans les options globales de Caddy, ce que la documentation de Caddy décrit comme la configuration de la journalisation en temps d’exécution plutôt que celle des accès HTTP.
Ce n’est donc pas tout à fait une installation standard inchangée, mais c’est aussi une approche différente de celle qui consiste à remplacer nginx par Caddy entièrement.
Je jeterai un coup d’œil plus attentif à cette PR. Pour l’instant, je suis principalement intéressé par savoir s’il y a suffisamment d’intérêt pour cette approche pour qu’un guide étape par étape en vaille la peine, plutôt que de commencer à en écrire un immédiatement.