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ückgemeldet, 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, dass 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.
IETF HTTP Web Push vs. W3C Push API via Twitter kommentieren