Mon blog

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 :

• HTTP non sécurisé, Flux Atom avec seulement les résumés,
• HTTP non sécurisé, Flux Atom avec tout le contenu,
• HTTPS, Flux Atom avec seulement les résumés,
• HTTPS, Flux Atom avec tout le contenu.

Merci à tous les signaleurs de bogue et notamment à Styx.