Blogging & Offenes Web

WebSub für eine persönliche Website - Wenn der Feed seine Updates ankündigt

Geschrieben von Adam Muiz 19 Oct 2026 Aktualisiert: 19 Oct 2026 9 Min. gelesen

Ein Feedreader kann einen neuen Artikel entdecken, indem er den Feed einer Website alle paar Minuten abruft. Das funktioniert, führt aber zu einer unbequemen Wahl: häufig prüfen und viele Anfragen ohne neue Inhalte senden oder seltener prüfen und eine längere Verzögerung hinnehmen. Kann eine persönliche Website mitteilen, dass sich ihr Feed geändert hat, ohne RSS oder Atom zu ersetzen?

WebSub ist eine mögliche Antwort. Es ist ein W3C-Protokoll, das Aktualisierungen von Publishern über einen Hub genannten Vermittler an Subscriber überträgt. Früher war das Protokoll als PubSubHubbub bekannt. WebSub ersetzt kein Feedformat und ist nicht dasselbe wie Browser-Push-Benachrichtigungen. Es ergänzt eine bereits vorhandene HTTP-Ressource um einen Server-zu-Server-Übertragungsweg.

Diese Unterscheidung ist wichtig. WebSub kann Aktualisierungen für kompatible Subscriber schneller verfügbar machen und unnötiges Polling verringern. Es garantiert jedoch weder, dass jeder Feedreader diesen Weg nutzt, noch macht es Polling überflüssig. Außerdem kommen Leases, Callbacks, Signaturen und ein weiterer Dienst hinzu, dessen Richtlinien und Verfügbarkeit eine Rolle spielen. Die entscheidende Frage lautet deshalb nicht einfach „Ist Push besser als Polling?“, sondern „Welche Verantwortlichkeiten fügt WebSub hinzu, und sind sie für diese Website gerechtfertigt?“

Den Feed behalten, den Weg der Aktualisierungen ändern

Atom ist ein XML-basiertes Syndikationsformat: Es beschreibt einen Feed und dessen Einträge. WebSub ist ein Übertragungsprotokoll. Sein Topic kann ein RSS- oder Atom-Feed, eine HTML-Seite oder eine andere HTTP- beziehungsweise HTTPS-Ressource sein. Für eine übliche persönliche Website bleibt ein Feed ein naheliegendes Topic, weil er Subscribern bereits eine strukturierte Liste von Beiträgen bietet.

Als Analogie helfen ein schwarzes Brett und eine Türklingel. Der Feed ist das schwarze Brett: Er enthält die aktuellen Informationen und bleibt jederzeit zugänglich. WebSub ergänzt die Klingel: Subscriber können sich benachrichtigen lassen, nachdem sich der Aushang geändert hat. Die Benachrichtigung ersetzt das Brett nicht, und wer die Klingel nicht nutzen kann, kann weiterhin selbst nachsehen.

Deshalb sollte auch der Begriff „Echtzeit“ vorsichtig verwendet werden. Ein Publisher kann einen Hub zeitnah informieren, doch die Zustellung hängt weiterhin vom Hub, vom Subscriber, von den Netzwerkbedingungen, von Wiederholungsversuchen und von Implementierungsrichtlinien ab. WebSub definiert einen Weg für Aktualisierungen; es verspricht weder eine allgemeingültige Latenz noch Exactly-once-Verarbeitung.

Vier Rollen bei einer Aktualisierung

Das Protokoll lässt sich leichter verstehen, wenn seine vier Begriffe klar getrennt werden:

Topic: die HTTP- oder HTTPS-Ressource, deren Änderungen von Interesse sind, etwa https://example.com/feed.atom.
Publisher: der Eigentümer dieses Topics. Er veröffentlicht die relevanten URLs und informiert den vorgesehenen Hub nach einer Aktualisierung.
Hub: der Vermittler, der Abonnementanfragen prüft und aktualisierte Inhalte verteilt.
Subscriber: ein über das Netzwerk erreichbarer Dienst, der Aktualisierungen anfordert und sie an einer Callback-URL empfängt.

Der grobe Ablauf in der aktuellen WebSub Recommendation sieht so aus:

Der Subscriber ruft ein Topic ab und entdeckt dessen Hub-URL sowie die kanonische Topic-URL.
Der Subscriber sendet eine Abonnementanfrage an den Hub.
Der Hub sendet eine Challenge an den Callback des Subscribers, um zu prüfen, ob das Abonnement tatsächlich angefordert wurde.
Wenn sich das Topic ändert, informiert der Publisher den Hub.
Der Hub sendet den aktualisierten Inhalt des Topics an aktive Subscriber.

Der Publisher benötigt keine Liste der Subscriber. Der Hub verwaltet diese Beziehung. Dadurch bleibt die Publisher-Seite vergleichsweise klein, während mehr Komplexität beim Hub und beim Subscriber liegt.

Was ein kleiner Publisher bereitstellen muss

Ein konformer Publisher muss mindestens eine Hub-URL und eine kanonische Topic-URL bekannt geben. WebSub verwendet dafür typisierte Weblinks. Die bei IANA registrierte Relation hub bezeichnet einen Dienst, bei dem Aktualisierungsbenachrichtigungen registriert werden können, während self das für das Abonnement verwendete Topic identifiziert.

Die Links können in HTTP-Link-Headern übertragen werden. Bei XML-Feeds und HTML-Seiten können sie außerdem als Link-Elemente eingebettet sein. Subscriber prüfen zuerst die HTTP-Header und untersuchen die Repräsentation, wenn dort keine entsprechenden Links vorhanden sind. Dieses Modell baut auf den typisierten Beziehungen und der Serialisierung des Link-Headers aus RFC 8288 auf.

Ein Atom-Feed könnte die folgenden Links auf Feed-Ebene enthalten:

<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Example Notes</title>
  <link rel="self"
        type="application/atom+xml"
        href="https://example.com/feed.atom" />
  <link rel="hub"
        href="https://hub.example.net/" />
  <!-- feed metadata and entries -->
</feed>

Die Domains sind Platzhalter und keine Empfehlung für einen öffentlichen Hub. Die self-URL verdient besondere Aufmerksamkeit: Sie ist die kanonische Topic-URL, die Subscriber an den Hub zurücksenden. Sie sollte die beabsichtigte Repräsentation ausliefern und stabil bleiben. Wenn ein Endpunkt mehrere Medientypen oder Sprachen aushandelt, erläutert die WebSub-Spezifikation, wie die Discovery stattdessen eine repräsentationsspezifische self-URL liefern kann.

Discovery ist nur die Hälfte der Publisher-Aufgabe. Nach der Veröffentlichung eines geänderten Topics muss der Publisher jeden von ihm angegebenen Hub informieren. Der Standard lässt diesen Publisher-zu-Hub-Mechanismus bewusst offen. Manche Hubs akzeptieren möglicherweise einen formularcodierten POST, doch diese Konvention ist kein universeller Befehl, der für jeden Anbieter übernommen werden kann. Eine CMS-Integration muss die aktuelle Dokumentation des gewählten Hubs befolgen und Fehler behandeln, ohne vorzugeben, eine erfolgreiche Artikelveröffentlichung hänge von einer sofortigen Hub-Antwort ab.

Warum die Subscriber-Seite schwieriger ist

Zwei Links zu einem Feed hinzuzufügen ist einfach. Einen Subscriber zu bauen bedeutet dagegen mehr, als lediglich einen Webhook-Endpunkt anzulegen.

Ein Subscriber sendet dem Hub eine formularcodierte Anfrage mit Callback, Modus und der gefundenen Topic-URL. Kann der Hub die Anfrage verarbeiten, antwortet er mit HTTP 202 Accepted, weil auf die Annahme eine asynchrone Prüfung folgt. Anschließend sendet der Hub eine GET-Anfrage mit einem zufälligen hub.challenge an den Callback. Der Subscriber gibt diese Challenge nur zurück, wenn Topic und Aktion zu einem ausstehenden Abonnement passen.

Abonnements sind Leases und keine dauerhaften Zusagen. Der Hub legt ihre Laufzeit fest, und der Subscriber muss sie vor dem Ablauf erneuern. Wenn Inhalte eintreffen, bestätigt der Callback den Empfang zügig mit einer 2xx-Antwort. Laut Spezifikation sollte diese Antwort bedeuten, dass die Nachricht empfangen wurde, nicht dass jede nachgelagerte Aufgabe erfolgreich abgeschlossen ist. Aufwendiges Parsen oder Indexieren kann dadurch nach der Bestätigung stattfinden. Zugleich benötigt der Subscriber eine eigene dauerhafte Verarbeitung und Beobachtbarkeit, wenn der Verlust einer Aktualisierung relevant wäre.

Die Zustellung erfolgt nicht exactly-once. Hubs sollten fehlgeschlagene Anfragen innerhalb ihrer eigenen Grenzen wiederholen, doch Duplikate, verspätete Zustellungen und endgültige Fehler bleiben Anliegen der Anwendung. Kennungen und Aktualisierungszeitpunkte von Feed-Einträgen bleiben daher wichtig. Gelegentliches Polling des Topics kann außerdem ein sinnvoller Wiederherstellungsweg sein und ist kein Eingeständnis, dass die Push-Idee gescheitert sei.

Die Sicherheitsdetails von 2026 sind keine optionale Dekoration

Die W3C-Veröffentlichungshistorie verzeichnet eine ursprüngliche Recommendation vom 23. Januar 2018 und eine neue Recommendation vom 2. Juni 2026. Das aktuelle Dokument ergänzt Schutzmaßnahmen gegen Cross-Site-Scripting-Risiken bei der Abonnementverifizierung. Das ist ein praktischer Grund, WebSub nicht allein nach einem alten Tutorial zu implementieren.

Die aktuelle Sicherheitsanleitung empfiehlt HTTPS nachdrücklich für alle Anfragen. Ein Subscriber sollte eine eindeutige, schwer zu erratende Callback-URL verwenden und ein kryptografisch zufälliges hub.secret bereitstellen. Wurde ein Secret übermittelt, signiert der Hub den Distribution-Body mit HMAC in X-Hub-Signature. Der Subscriber sollte die Signatur neu berechnen und einen nicht übereinstimmenden Payload verwerfen. Laut Spezifikation sollte mindestens SHA-256 verwendet werden, wenn dem Transport selbst nicht vertraut werden kann.

Die Verifizierungs-Challenge braucht eigene Schutzmaßnahmen. Die aktuelle Recommendation verlangt für die zurückgegebene Challenge einen sicheren Medientyp sowie X-Content-Type-Options: nosniff. Sie rät außerdem zu Einschränkungen der Challenge, etwa einer Längenbegrenzung und der Ablehnung binärer Daten. Diese Regeln verhindern, dass ein Callback auf einer vertrauenswürdigen Domain zum Vektor für reflektierte Inhalte oder Downloads wird.

Signaturen machen nicht jeden Teil der Anfrage vertrauenswürdig. Die WebSub-Signatur deckt den Body ab, nicht beliebige Request-Header. HTTPS schützt weiterhin den Transport, und der Subscriber muss Zustellungen seinem eigenen Abonnementzustand zuordnen, statt jeden POST zu akzeptieren, der den Callback erreicht.

Wann sich WebSub lohnt

Für eine persönliche Website ist der deutlichste Anwendungsfall ein stabiler öffentlicher Feed, eine Publishing-Pipeline mit einem zuverlässigen Post-Publish-Hook und bekannte Consumer, die WebSub verstehen. Unter diesen Bedingungen kann die Änderung auf Publisher-Seite überschaubar bleiben: Discovery-Links veröffentlichen, den gewählten Hub informieren, das Ergebnis protokollieren und den Feed gültig halten.

Weniger überzeugend ist der Einsatz, wenn kein relevanter Consumer WebSub nutzt, ein öffentlicher Callback nicht möglich ist oder eine weitere betriebliche Abhängigkeit den Wartungsaufwand nicht rechtfertigt. Polling ist weniger elegant, aber leichter zu untersuchen, und bedingte HTTP-Anfragen können es hinreichend effizient machen. Eine kleine Website wird nicht weniger „offen“, nur weil sie den einfacheren Mechanismus wählt.

Außerdem besteht ein wesentlicher Unterschied zwischen der Nutzung und dem Betrieb eines Hubs. Ein Publisher kann Speicherung der Abonnements, Verifizierung, Wiederholungsverhalten und Zustellung an einen Hub delegieren. Wer den Hub selbst hostet, übernimmt diese Aufgaben wieder. Das kann aus Kontroll- oder Datenschutzgründen angemessen sein, ist aber ein Dienstbetriebsprojekt und keine bloße Erweiterung des Feeds um zwei Links.

Eine vorsichtige Checkliste für die Einführung

Sicherstellen, dass Feed oder Topic eine stabile kanonische URL und den richtigen Medientyp besitzen.
Einen Hub erst auswählen, nachdem seine aktuellen Richtlinien, Grenzen, Sicherheitsfunktionen und sein Betriebszustand geprüft wurden.
Zueinander passende Links mit rel="self" und rel="hub" in einem vom Topic unterstützten Format veröffentlichen.
Den Hub erst informieren, nachdem das aktualisierte Topic öffentlich abrufbar ist.
Den normalen Feedzugriff nicht entfernen und nicht davon ausgehen, dass jeder Reader den Hub verwendet.
Bei einer Subscriber-Implementierung Lease-Erneuerung, doppelte Zustellung, schnelle Bestätigung, Signaturprüfung und sichere Challenge-Antworten einplanen.
Die tatsächlich implementierte Rolle testen. WebSub Rocks, auf das die W3C-Spezifikation verweist, bietet getrennte Tests für Publisher, Subscriber und Hubs.
Sowohl Publishing- als auch Zustellungsweg überwachen und Polling als möglichen Fallback beibehalten, wenn Aktualität wichtig ist.

Fazit

WebSub macht aus einem Feed kein anderes Produkt. Es bietet einer vorhandenen Webressource eine standardisierte Möglichkeit, einen Hub bekannt zu geben, und kompatiblen Subscribern einen callbackbasierten Weg für Aktualisierungen. Für einen Publisher kann die sichtbare Oberfläche klein bleiben. Im Gesamtsystem machen Verifizierung, Leases, Wiederholungsversuche, Signaturen und Hub-Richtlinien die Abwägung jedoch umfangreicher.

Damit ist WebSub weder ein automatisches Upgrade noch grundsätzlich unnötige Technik. Es ist nützlich, wenn eine zeitnahe Server-zu-Server-Zustellung ein konkretes Problem löst und die zusätzliche Abhängigkeit beobachtet und gepflegt werden kann. Fehlen diese Bedingungen, bleiben ein gültiger Feed und sorgfältiges Polling ein solides Design. Die offene Frage für jede persönliche Website lautet nicht, ob Push moderner klingt, sondern ob ihre tatsächlichen Leser und ihr Publishing-Workflow von dem zusätzlichen Weg profitieren.