Hébergement statique

Un site Chinaski construit est une simple arborescence d'HTML/CSS/images affûtée pour le service statique : le déploiement typique est un reverse proxy ou un hébergeur statique lisant cette sortie. Cette page couvre le service avec nginx ou Caddy, comment fonctionnent les fichiers de redirection (l'hébergement à la Netlify) et quelles routes un site « statique » doit quand même transmettre au CMS.

La sortie construite

Un répertoire par langue (ou une seule racine pour les sites monolingues) :

• index.html par répertoire, avec une sémantique try-files traduisant les URL en chemins.
• _redirects : les règles de redirection à la Netlify que le builder génère à chaque build (redirections de slug avec leurs codes de statut configurés).
• _redirects.caddy : un fichier compagnon avec les mêmes redirections dans la syntaxe native de Caddy, prêt à inclure dans un Caddyfile.
• Fichiers PWA (sw.js, manifest, page offline) avec leurs propres directives de cache.
• Imposition complète du domaine canonique : un bloc _redirects généré qui fait un 301 de l'hôte alternatif www/nue vers celui correspondant à votre Site URL (voir la page du domaine canonique pour sa syntaxe exacte).

Les routes qu'un site statique doit quand même transmettre

Deux familles d'URL ne peuvent pas être servies statiquement et doivent être transmises en reverse proxy au démon du CMS :

• /forms/* : pages de formulaires publics et POST de soumission. Sans transmission, chaque soumission de formulaire retourne 404.
• /documents/* : téléchargements de documents (comptage des téléchargements, contrôle de l'état publié). Sans transmission, chaque URL de document fait un 404.

Les deux exemples fournis font exactement cela

Le dépôt fournit des vhosts prêts à copier et éditer :

• nginx (deploy/chinaski.nginx.example et son frère plus complet -conf.example) : sert par racine de documents, transmet /forms/ et /documents/ à 127.0.0.1:<port du CMS>, définit un cache long sur les fonts/assets, pas de cache pour le service worker, un cache court sur l'HTML, plus les en-têtes de sécurité au niveau de l'application en ceinture et bretelles. TLS : lancez certbot contre le vhost activé.
• Caddy (deploy/chinaski.Caddyfile.example) : un bloc par instance, transmet au port loopback du CMS, définit X-Forwarded-For/Proto/Host explicitement, ajoute des politiques de cache reflétant celle de nginx, et route les chemins honeypot de scanner (/.env, /.git/config, sondes wp-login…) vers le CMS pour qu'ils soient journalisés et tarpitted au lieu d'être répondues par le serveur web.

La transmission en loopback est délibérée : les proxies se connectant depuis 127.0.0.1 sont de confiance par défaut, donc aucun CHINASKI_TRUSTED_PROXIES supplémentaire n'est nécessaire. Si votre proxy est à un saut de réseau de conteneurs, ajoutez ce réseau à CHINASKI_TRUSTED_PROXIES.

La synchronisation de la racine nginx de deploy.sh

À chaque déploiement, le script synchronise la racine de documents nginx contre le mode de langue courant : vers output/ pour les sites monolingues ou output/<langue par défaut> sinon, en éditant seulement les configs qui référencent cette installation. Il exécute nginx -t avant le reload et avertit, en laissant en sécurité, si le test de config échoue.

Les fichiers de redirection

Le builder émet trois fichiers générés à la racine de sortie relatifs aux redirections. Voir la page des formats de redirection pour le détail fichier par fichier, y compris la ligne de domaine canonique spécifique à Caddy.

L'hébergement à la Netlify

Le builder écrit les règles de redirection dans le format _redirects de Netlify (simples lignes ancien-slug → nouveau-slug avec votre code de statut choisi). Deux choses à savoir avant de pointer Netlify vers la sortie :

• Les redirections de motif (jokers * avec placeholders de capture) ne sont délibérément pas écrites dans _redirects : le format de fichier simple ne peut pas les exprimer en sécurité ; elles vivent dans votre configuration de proxy.
• Le bloc de domaine canonique généré utilise la syntaxe de force 301! de Caddy dans le même fichier. Un analyseur _redirects Netlify strict rejettera cette ligne ; vérifiez/éditez-la avant d'envoyer le fichier vers un hébergeur non-Caddy, ou remplacez-la.

Note ceinture-et-bretelles : les en-têtes de sécurité définis par l'application CMS sont aussi présents dans les vhosts d'exemple, car un proxy peut servir des réponses en cache avant que l'application n'ait une chance de répondre.

Dans cette section

• Hébergement statique avec Caddy
• Hébergement statique avec nginx
• Formats des fichiers de redirection