Il y a un vieux problème sur ce blog, qui se pose depuis que
j'ai activé l'accès en
HTTPS : les flux de syndication ne
fonctionnaient pas avec un grand nombre
d'agrégateurs. J'ai contourné le problème
en ayant désormais deux flux, un en HTTPS
et un sans.
Quel est le problème ? Comme j'utilise une
AC gratuite et automatique, CAcert, qui n'est pas dans tous les magasins
de certificats, loin de
là, je ne peux pas forcer l'usage de HTTPS,
cela perturberait trop de lecteurs. (Pourtant, j'ai publié des
enregistrements DANE mais, malheureusement,
il y a encore bien des navigateurs qui,
bêtement, ne les utilisent pas. Demandez aux auteurs de votre
navigateur et dites-leur bien que DANE est la bonne solution à ce problème.)
Pour les flux de syndication Atom,
j'avais pensé résoudre le problème en utilisant des liens
« presque absolus ». Ces liens commencent par deux
barres obliques, par exemple
//www.bortzmeyer.org/toot.html et le logiciel
client est supposé, pour le plan (http: ou
https:) utiliser le même plan que celui
utilisé pour récupérer le fichier où il y avait ces liens.
Avec tous les navigateurs Web, ça marche, le
navigateur ajoute http: ou https: selon l'URL utilisé pour récupérer
la ressource originale. J'ai malheuresement constaté que ce n'était
pas le cas avec les agrégateurs de
syndication. De nombreux agrégateurs ne comprennent pas
ces liens, et font, par exemple, des requêtes pour une ressource
//www.bortzmeyer.org/toot.html, ce qui produit
une erreur 404. Le problème semble affecter, entre autres,
Liferea ou spaRSS. Certains agrégateurs ont corrigé
(Netvibes) mais d'autres trainent la patte.
Qui a raison ? Ce n'est pas évident. La syntaxe des
URI est normalisé par le RFC 3986, qui semble autoriser ces URI relatifs commençant
par deux barres obliques (section 4.2 du RFC, « A relative reference that begins with two slash characters is termed
a network-path reference », et l'exemple
//g en 5.4.1). Ces URI « double slash » sont également appelés
« protocol-relative
URIs » ou « protocol-less URIs », termes tout à fait
erronés puisque le plan n'est pas forcément un protocole,
« scheme-relative URIs » serait un meilleur terme. De toute façon,
personnellement, je trouve le RFC peu clair sur ce point : ces URI sont
légaux mais leur sémantique est mal expliquée. En attendant, le
RFC sur Atom (RFC 4287) semble décourager
l'usage de liens non-absolus (sections 4.2.7.1 et 4.2.6). (Pour
RSS, les liens non-absolus sont clairement
interdits car RSS n'a pas de notion d'« URL de base »,
contrairement à Atom.)
Un autre inconvénient de ces liens presques absolus étaient
qu'ils ne donnent pas le résultat attendu si le flux Atom a été
récupéré par un autre moyen que HTTP ou HTTPS (par exemple un
fichier sur le disque local).
Plutôt
que d'essayer de faire corriger tous les agrégateurs, j'ai préféré
offrir le choix au lecteur, qui va donc devoir manuellement
sélectionner le flux qu'il préfère.
Voici donc les quatre flux Atom. Il y
a en effet le choix entre TLS ou pas
(pour la sécurité et la vie privée) et article complet ou pas :
Merci à tous les signaleurs de bogue et notamment à Styx.
