Résumé

  • PubSubHubbub a remplacé les vérifications incessantes des lecteurs de flux par une chaîne à trois acteurs : éditeur, hub et abonné. Le projet de 2010 confiait au hub la récupération des nouveautés et leur distribution. La rapidité venait d’un guichet intermédiaire.
  • Dans la recommandation WebSub de 2018, un 202 Accepted accuse réception d’une demande qui reste à valider. Le hub vérifie le point de retour et attribue une durée limitée ; l’abonné doit renouveler avant l’échéance. Même ouvert, le protocole fonctionne avec une liste de distribution qui expire.

Les lecteurs cessaient de sonner à toutes les portes

Un agrégateur de flux pouvait demander régulièrement à chaque site si un nouvel article était arrivé. Les réponses inchangées consommaient des requêtes et du temps. Le projet PubSubHubbub Core 0.3 de février 2010 mettait en place un autre trajet. L’éditeur indiquait un hub dans son flux Atom ou RSS ; quand le flux changeait, il avertissait ce hub. Celui-ci récupérait la version modifiée et envoyait les nouveautés aux adresses de rappel des abonnés.

L’éditeur n’avait plus à recevoir une foule de lecteurs demandant tous la même chose. Le hub devenait son bureau de distribution. L’implémentation de référence du projet visait Google App Engine, mais les auteurs précisaient que chacun pouvait exploiter un hub. Aucune entreprise n’était indispensable au protocole. Pour une inscription donnée, toutefois, le trajet passait par le hub annoncé par l’éditeur.

L’abonné devait fournir une adresse de rappel accessible depuis le réseau. Le hub y envoyait un hub.challenge, que le destinataire devait renvoyer sans modification. C’était la preuve que l’adresse voulait réellement recevoir le flux, au lieu d’avoir été saisie par un tiers. Le hub conservait aussi la liste des abonnements et organisait les envois. Le travail retiré aux lecteurs n’avait pas disparu : il avait changé de bureau.

Un ticket reçu avant l’inscription

Le W3C a publié WebSub comme recommandation en janvier 2018, nouveau nom de PubSubHubbub. Sa spécification datée conservait l’éditeur, le hub et l’abonné tout en étendant la notion de sujet à des ressources Web. L’éditeur annonçait sujet et hub ; l’abonné envoyait sa demande au hub ; le hub livrait ensuite le contenu par POST à l’adresse de rappel.

La réponse HTTP 202 Accepted peut tromper un opérateur pressé. La norme exige cette réponse lorsque le hub sait traiter la demande, puis prévoit encore la validation et la vérification du destinataire. Le hub peut refuser certains sujets ou certaines adresses selon sa politique. Il interroge le point de rappel avec un défi et contrôle la réponse. Le reçu du guichet ne prouve ni une inscription active ni une livraison.

Le calendrier imposait une autre condition. Le projet de 2010 prévoyait des durées limitées et décrivait une revérification automatique à l’initiative du hub. La recommandation de 2018 obligeait le hub à faire respecter les expirations et interdisait les durées perpétuelles. Le hub envoyait hub.lease_seconds pendant la vérification ; l’abonné devait redemander son inscription avant la fin de ce délai. Un éditeur pouvait continuer à publier tandis qu’un destinataire qui oubliait de renouveler sortait de la distribution. Le contenu restait sur le Web ; son acheminement programmé s’arrêtait.

La norme permettait plusieurs hubs et des réalisations indépendantes. Chaque hub choisi restait néanmoins responsable de l’admission, du contrôle, de l’horloge et des envois. L’éditeur devait signaler les mises à jour aux hubs désignés, mais le moyen de cette notification était laissé à leur accord. Une fois informé, le hub récupérait le sujet et POSTait le contenu vers les abonnés. Ses propres limites encadraient les nouvelles tentatives de livraison. « Publié », « reçu par le hub », « demande acceptée », « rappel vérifié », « bail actif » et « livré » étaient six états, pas un seul bouton magique nommé temps réel.