IETF HTTP Web Push vs. W3C Push API

Gemäß Entwurf des IETF ist HTTP Web Push

A simple protocol for the delivery of realtime events to user agents is described. This scheme uses HTTP/2 server push.

Andockend an der W3C Push API1, die in Firefox und Chrome bereits implementiert ist und in Edge zur Stunde wird, kanalisiert das Web Push der IETF serverseits. Als Zielsetzung wird in dem Entwurf über die bereits sattsam genutzten Benachrichtigungen der Hinblick auf einen Bandbreite- und darum Batterie-schonende Sitzung basierenden Mechanismus gelegt, bei dem einzelne Botschaften in Bündel zusammengefasst und übertragen werden.

Polling als auch persistente Verbindungen werden hiermit endgültig von Ereignis-orientierten Benachrichtigungen nicht nur abgelöst, sondern deren Form auch standardisiert und ihre Funktion Browser-übergreifend einheitlich sichergestellt.

Sichergestellt im Übrigen auch, da dieses wie alle anderen Protokolle der jüngeren Zeit ausschließlich https für den Transport erlauben; wenngleich der hierfür vorgesehene TCP-Port 443 aufgrund des kompromissloseren Umgang mit Latenz ausdrücklich nicht verwendet werden muss, sondern explizit der für »HTTP alternative services« bereits offiziell reservierte Port verwendet werden soll, ein auf dem dann auch Timeouts von bis zu 2 Stunden und 4 Minuten erlaubt sein sollen – wobei ich nicht verstanden habe, warum ausgerechnet 124 Minuten.

Beim Austausch der Details zur jeweiligen Sitzung wurde Wert darauf gelegt, auf der Klaviatur des HTTP-Standard zu spielen: HTTP/1.1 201 Created quittiert etwa erfolgreich angelegte Subscription oder Subscription Set, HTTP/1.1 202 Accepted gibt für den Fall das die gewünscht ist eine Zustellungsbestätigung zurück an den Application Server, HTTP/1.1 400 Bad Request übermittelt die allgemeine oder spezielle Unfähigkeit, HTTP/1.1 429 Too Many Requests trägt der dennoch früher oder später auftretenden Überlastung Rechnung. Und mit einem HTTP DELETE-Request wird schließlich etwa die Entgegennahme durch den User-Agent zurück gemeldet, der daraufhin ein schlichtes, schlankes HTTP/1.1 204 No Content erhält, wohingegen der Application Server per HTTP/1.1 410 Gone über das Dahinscheiden seines Klienten informiert wird. Damit sichergestellt ist, das eine Push Message zumindest einmal beim User-Agent eingetroffen ist, wird der in die Pflicht genommen diese mit einem DELETE-Request zu beantworten, woraufhin der Push Service wiederum ein altbekanntes HTTP/1.1 204 No Content zurückzusenden oder, wenn er das vergeblich versucht, dies einfach zu verwerfen. Dem Application Server hat er nach Ablauf der Gültigkeit mit HTTP/1.1 410 Gone vom Dahinscheiden des User-Agent zu berichten, woraufhin der seinerseits das Aufräumen beginnen kann.

Wo ich mich früher gefragt habe, wann die ungenutzten HTTP/1.1 Stati denn mal verwendet werden würden, frage ich mich inzwischen, welche noch übrig sind.

Mit Hilfe asynchroner Benachrichtigung kann auf die Zustellung reagiert werden, mittels Time-To-Live wird die Lebenszeit der Botschaften Sekunden-granular beschränkt sowie anhand ihrer Referenz können Push Messages durch solche mit neuen Werten ersetzt werden und unter Verwendung von Urgency verschickte werden bevorzugt behandelt, so denn möglich. Der Ausgestaltung auf Anwendungsebene bleiben werden keine Grenzen gesetzt. Und der Anwendungsebene wird die Konstruktion eigener Transportschichten oder die Zuhilfenahme von Brückentechnologie vermieden und die Entwickler können sich auf das Wesentlich konzentrieren.

Der langen Schreibe kurzer Sinn: Man sieht schon bar meiner Aufzählung des Triplet User-Agent, Push Service und Application Server, das die drei einen Dreiklang bilden. Der Nutznießer in Form eines Browsers etwa, bildet ab, was dem Broker Push Service vom Application Server übergeben wurde, vice versa. Wie genau die Push API mit IETF Web Push interagiert kann man in den Fussnote verlinkten Sequenzdiagramm auf einen Blick einsehen. Spannende Zeiten jedenfalls, in denen ein solches als spannendste Infografik im Abendprogramm gelten kann, ganz ohne Ironie.

  1. Sequenzdiagramm der Push API des W3C []

Ad Blocker Blocker Blocker!

Sie haben keinen Ad Blocker aktiviert, möglicherweise weil sie Kostenloskulturkritiker hereingefallen sind.

Ad Blocker Blocker schaden der geistigen Gesundheit, denn sie verblöden den Kostenloskulturkonsumenten.

Geben sie Ad Blocker Blockern keine Chance.

Installieren sie noch heute uBlock oder ähnliche!