À la question « est-il possible d'enlever l’extension .html de mon site web généré avec Pelican » je vous répond oui ! C'est d'ailleurs ce que nous allons voir dans cet article.
Le besoin
Nous avons affaire à un besoin d'ordre décoratif. Il est courant de voir dans les blogs et sites web des URL qui ne contiennent que le chemin et le nom d'article comme https://example.com/articles/2017/super-article.
L'idée derrière ça c'est que l'URL doit être compréhensible pour un humain et refléter la ressource et ses caractéristiques principales. Par exemple la catégorisation en année de publication, courant sur les blogs. Cela permet de savoir en un coup d'œil si l'article est frais ou au contraire périmé.
Quel rapport avec Pelican me direz-vous ?
Et bien par défaut Pelican génère des fichiers HTML qu'il suffit ensuite de servir avec un serveur HTTP. Le serveur se sert de l'extension .html pour savoir que c'est du HTML et ainsi l'afficher directement dans le navigateur au lieu de le proposer au téléchargement (en retournant le bon type MIME).
Sauf que cette extension n'apporte rien au niveau sémantique, car sur un blog on sait que l'on va tomber sur des pages HTML. Il est donc tentant de supprimer cette extension qui fait un peu années 90.
La solution
Deux composants à modifier pour rendre ce hack possible.
Au niveau de Pelican
On va dire à Pelican de continuer à générer des fichiers HTML mais de supprimer l'extension au niveau des liens entre les pages. Si les liens sur votre site ne sont pas fixés en dur mais bien réalisés cette étape permettera de transformer tous les liens de manière automatique.
# Save pages and articles as HTML bug link between them without HTML
#
# HTTP server will do the translation and serve the file without extension
# using rewrite rules
ARTICLE_SAVE_AS = '{slug}.html'
ARTICLE_URL = '{slug}'
PAGE_SAVE_AS = '{slug}.html'
PAGE_URL = '{slug}'
Au niveau de nginx
Il faut ensuite demander à nginx d'essayer de rajouter l'extension .html à un fichier lorsqu'il essaye de résoudre une URL. Cela se fait de la façon suivante :
location / {
try_files $uri $uri.html $uri/ =404;
}
Ainsi, pour une URL /toto nginx essayera dans l'ordre :
- Le nom exact du fichier : toto ;
- Le nom du fichier en lui rajoutant l'extension : toto.html ;
- Le dossier avec ce nom : toto/ ;
- Ou alors affichera une erreur 404.
Étant donné que toutes les extensions auront été supprimées dans les liens HTML des pages Pelican, on devrait se retrouver dans le second cas. Cette solution a également l'avantage suivant : si quelqu'un a déjà épinglé votre article pour le lire après avec l'extension toto.html alors ce lien sera encore valide ! On évitera ainsi la catastrophe en balançant une 404 à notre lecteur curieux.
Conclusion
Hack assez gadget ou solution ultime pour cacher aux autres que vous utilisez un blog statique ?
Pour moi juste un moyen de renforcer la sémantique des URLs. Sans doute le fait d'écrire des APIs qui me sensibilise un peu à cette hygiène de l'URL.
Vous ne verrez sans doute pas tout de suite cette modification appliquée sur ce blog car je suis en plein chantier au niveau de la gestion de mes serveurs, mais un jour ça sera là ! En tout cas j'ai essayé dans un environnement de test et ça fonctionne.
Sources :