Resumen

  • PubSubHubbub evitaba que cada lector preguntara una y otra vez a cada web si había novedades. En el borrador de 2010, el editor avisaba a un hub; el hub obtenía el flujo actualizado y repartía los cambios a las direcciones de retorno. La velocidad tenía intermediario.
  • La recomendación WebSub de 2018 fijó las condiciones de esa mesa de reparto: 202 Accepted confirmaba la recepción de una solicitud, todavía pendiente de verificación; el abono caducaba y el suscriptor debía renovarlo antes del plazo.

Se acabó llamar a cada puerta

Un lector de noticias podía descargar los mismos flujos cada pocos minutos. Casi siempre encontraba lo que ya tenía. El borrador PubSubHubbub Core 0.3 de febrero de 2010 propuso una ruta distinta: el editor anunciaba un hub en su flujo Atom o RSS y le avisaba cuando había cambios. El hub recuperaba el flujo, identificaba las novedades y las enviaba a las direcciones de retorno de los suscriptores.

El servidor del editor dejaba de atender a una multitud que hacía la misma pregunta. Un distribuidor mantenía la lista. La implementación de referencia del borrador apuntaba a Google App Engine, pero el propio texto decía que cualquiera podía operar un hub. El protocolo estaba abierto; cada suscripción particular dependía del hub que el editor había anunciado.

Para solicitar una plaza, el suscriptor entregaba una dirección de retorno accesible desde la red. El hub enviaba allí un hub.challenge; el destinatario tenía que devolver exactamente el valor recibido. Así se comprobaba que alguien no había usado una dirección ajena para suscribirla o darla de baja. El hub administraba la lista y programaba el reparto. La carga que salía de los lectores entraba en una oficina nueva.

El 202 era un recibo, no la primera entrega

W3C anunció WebSub como recomendación en enero de 2018. Era el nuevo nombre de PubSubHubbub. Su especificación de 2018 conservó editor, hub y suscriptor, y permitió tratar como tema un recurso web más allá de los flujos. El editor anunciaba el tema y el hub; el suscriptor enviaba un POST; el hub entregaba el contenido con otro POST a la dirección de retorno.

El código HTTP 202 Accepted parecía una confirmación rotunda, pero significaba que el hub había recibido la solicitud y seguiría con la validación. El hub podía rechazar temas o direcciones según sus propias reglas. Después tenía que comprobar el retorno mediante un desafío. La petición recibida, la suscripción verificada y la noticia entregada eran tres estados diferentes.

El plazo añadió un cuarto. El borrador de 2010 admitía periodos de suscripción y describía una renovación automática iniciada por el hub mediante una nueva comprobación. En 2018, la recomendación obligó a los hubs a hacer cumplir el vencimiento y prohibió los periodos perpetuos. El hub indicaba hub.lease_seconds al verificar; el suscriptor debía volver a solicitar el abono antes de que se agotara. Un flujo podía seguir publicándose y, aun así, dejar de llegar por esta ruta a quien había perdido su turno de renovación.

La norma admitía varios hubs y operadores independientes. El editor elegía cuáles anunciaba. Cada uno podía aplicar políticas de admisión, verificar el retorno, controlar el reloj y gestionar los reintentos de entrega. El editor debía informar a sus hubs de los cambios; la forma exacta de avisarles quedaba a su acuerdo. El hub obtenía entonces el contenido y lo enviaba. El eslogan «en tiempo real» tapaba una secuencia más precisa: publicación, aviso al hub, solicitud recibida, retorno confirmado, plazo vigente y entrega efectiva.