{"id":9113,"date":"2016-06-05T18:33:00","date_gmt":"2016-06-05T16:33:00","guid":{"rendered":"http:\/\/udo.springfeld.eu\/blog\/?p=9113"},"modified":"2021-01-08T13:52:15","modified_gmt":"2021-01-08T12:52:15","slug":"ietf-http-web-push-vs-w3c-push-api","status":"publish","type":"post","link":"https:\/\/udo.springfeld.eu\/blog\/2016\/06\/05\/ietf-http-web-push-vs-w3c-push-api\/","title":{"rendered":"IETF HTTP Web Push vs. W3C Push API"},"content":{"rendered":"<p>Gem\u00e4\u00df Entwurf des IETF ist <strong>HTTP Web Push<\/strong><\/p>\n<blockquote><p>A simple protocol for the delivery of realtime events to user agents is described. This scheme uses HTTP\/2 server push.<\/p>\n<footer><a href=\"https:\/\/tools.ietf.org\/html\/draft-ietf-webpush-protocol-06\">IETF Web Push Protocol Draf<\/a> #6<\/footer>\n<\/blockquote>\n<p>Andockend an der W3C Push API<sup><a href=\"#footnote_0_9113\" id=\"identifier_0_9113\" class=\"footnote-link footnote-identifier-link\" title=\"Sequenzdiagramm der Push API des W3C\">1<\/a><\/sup>, die <a href=\"http:\/\/caniuse.com\/#feat=push-api\">in Firefox und Chrome bereits implementiert ist<\/a> und <a href=\"http:\/\/status.modern.ie\/pushapi\">in Edge zur Stunde wird<\/a>, kanalisiert das Web Push der IETF serverseits. Als Zielsetzung wird in dem Entwurf \u00fcber die bereits sattsam genutzten Benachrichtigungen der Hinblick auf einen Bandbreite- und darum Batterie-schonende Sitzung basierenden Mechanismus gelegt, bei dem einzelne Botschaften in B\u00fcndel zusammengefasst und \u00fcbertragen werden.<\/p>\n<p>Polling als auch persistente Verbindungen werden hiermit endg\u00fcltig von Ereignis-orientierten Benachrichtigungen nicht nur abgel\u00f6st, sondern deren Form auch standardisiert und ihre Funktion Browser-\u00fcbergreifend einheitlich sichergestellt.<\/p>\n<p>Sichergestellt im \u00dcbrigen auch, da dieses wie alle anderen Protokolle der j\u00fcngeren Zeit ausschlie\u00dflich https f\u00fcr den Transport erlauben; wenngleich der hierf\u00fcr vorgesehene TCP-Port 443 aufgrund des kompromissloseren Umgang mit Latenz ausdr\u00fccklich nicht verwendet werden muss, sondern explizit der f\u00fcr \u00bbHTTP alternative services\u00ab bereits offiziell reservierte Port verwendet werden soll, ein auf dem dann auch Timeouts von bis zu 2 Stunden und 4 Minuten erlaubt sein sollen &#8211; wobei ich nicht verstanden habe, warum ausgerechnet 124 Minuten.<\/p>\n<p>Beim Austausch der Details zur jeweiligen Sitzung wurde Wert darauf gelegt, auf der Klaviatur des HTTP-Standard zu spielen: <em>HTTP\/1.1 201 Created<\/em> quittiert etwa erfolgreich angelegte <em>Subscription<\/em> oder <em>Subscription Set<\/em>, <em>HTTP\/1.1 202 Accepted<\/em> gibt f\u00fcr den Fall das die gew\u00fcnscht ist eine Zustellungsbest\u00e4tigung zur\u00fcck an den Application Server, <em>HTTP\/1.1 400 Bad Request<\/em> \u00fcbermittelt die allgemeine oder spezielle Unf\u00e4higkeit, <em>HTTP\/1.1 429 Too Many Requests<\/em> tr\u00e4gt der dennoch fr\u00fcher oder sp\u00e4ter auftretenden \u00dcberlastung Rechnung. Und mit einem HTTP DELETE-Request wird schlie\u00dflich etwa die Entgegennahme durch den User-Agent zur\u00fcckgemeldet, der daraufhin ein schlichtes, schlankes <em>HTTP\/1.1 204 No Content<\/em> erh\u00e4lt, wohingegen der Application Server per <em>HTTP\/1.1 410 Gone<\/em> \u00fcber das Dahinscheiden seines Klienten informiert wird. Damit sichergestellt ist, dass eine <strong>Push Message<\/strong> 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 <em>HTTP\/1.1 204 No Content<\/em> zur\u00fcckzusenden oder, wenn er das vergeblich versucht, dies einfach zu verwerfen. Dem Application Server hat er nach Ablauf der G\u00fcltigkeit mit <em>HTTP\/1.1 410 Gone<\/em> vom Dahinscheiden des User-Agent zu berichten, woraufhin der seinerseits das Aufr\u00e4umen beginnen kann.<\/p>\n<p>Wo ich mich fr\u00fcher gefragt habe, wann die ungenutzten HTTP\/1.1 Stati denn mal verwendet werden w\u00fcrden, frage ich mich inzwischen, welche noch \u00fcbrig sind.<\/p>\n<p>Mit Hilfe asynchroner Benachrichtigung kann auf die Zustellung reagiert werden, mittels Time-To-Live wird die Lebenszeit der Botschaften Sekunden-granular beschr\u00e4nkt sowie anhand ihrer Referenz k\u00f6nnen Push Messages durch solche mit neuen Werten ersetzt werden und unter Verwendung von <i>Urgency<\/i> verschickte werden bevorzugt behandelt, so denn m\u00f6glich. Der Ausgestaltung auf Anwendungsebene bleiben werden keine Grenzen gesetzt. Und der Anwendungsebene wird die Konstruktion eigener Transportschichten oder die Zuhilfenahme von Br\u00fcckentechnologie vermieden und die Entwickler k\u00f6nnen sich auf das Wesentlich konzentrieren.<\/p>\n<p>Der langen Schreibe kurzer Sinn: Man sieht schon bar meiner Aufz\u00e4hlung des Triplet User-Agent, Push Service und Application Server, das die drei einen Dreiklang bilden. Der Nutznie\u00dfer in Form eines Browsers etwa, bildet ab, was dem Broker Push Service vom Application Server \u00fcbergeben wurde, vice versa. Wie genau die Push API mit IETF Web Push interagiert kann man in den Fussnote verlinkten Sequenzdiagramm auf einen Blick einsehen.<\/p>\n<ol class=\"footnotes\"><li id=\"footnote_0_9113\" class=\"footnote\"><a href=\"https:\/\/w3c.github.io\/push-api\/#sequence-diagram\">Sequenzdiagramm der Push API des W3C<\/a> [<a href=\"#identifier_0_9113\" class=\"footnote-link footnote-back-link\">&#8617;<\/a>]<\/li><\/ol>","protected":false},"excerpt":{"rendered":"<p>Gem\u00e4\u00df 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. IETF Web Push Protocol Draf #6 Andockend an der W3C Push API1, die in Firefox und Chrome bereits implementiert ist und in Edge zur Stunde wird, kanalisiert [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[567],"tags":[2455,2456,2458,2457],"class_list":["post-9113","post","type-post","status-publish","format-standard","hentry","category-definitionen","tag-http-web-push","tag-ietf","tag-push-api","tag-w3c"],"_links":{"self":[{"href":"https:\/\/udo.springfeld.eu\/blog\/wp-json\/wp\/v2\/posts\/9113","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/udo.springfeld.eu\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/udo.springfeld.eu\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/udo.springfeld.eu\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/udo.springfeld.eu\/blog\/wp-json\/wp\/v2\/comments?post=9113"}],"version-history":[{"count":9,"href":"https:\/\/udo.springfeld.eu\/blog\/wp-json\/wp\/v2\/posts\/9113\/revisions"}],"predecessor-version":[{"id":10989,"href":"https:\/\/udo.springfeld.eu\/blog\/wp-json\/wp\/v2\/posts\/9113\/revisions\/10989"}],"wp:attachment":[{"href":"https:\/\/udo.springfeld.eu\/blog\/wp-json\/wp\/v2\/media?parent=9113"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/udo.springfeld.eu\/blog\/wp-json\/wp\/v2\/categories?post=9113"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/udo.springfeld.eu\/blog\/wp-json\/wp\/v2\/tags?post=9113"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}