AJAX

HTML5 Server-Sent-Events: Per JavaScript auf Server-Requests reagieren

19. Februar 2013
von

Mit dem XMLHttpRequest-Objekt ist es bereits möglich, mit dem Webserver zu kommunizieren, ohne dass das HTML-Dokument neu geladen werden muss. Das Server-Sent-Event, das mit HTML5 eingeführt wurde, erlaubt es, ohne Neuladen des Dokumentes auf Server-Requests zu reagieren. Auf diese Weise ist es beispielsweise sehr einfach möglich, einen Artikelbestand aktuell zu halten oder eine terminierte Ausgabe (mit Server- statt Clientzeit) ohne Neuladen zu realisieren.

serversentevents

Server-Sent-Events: Event definieren und darauf reagieren

Zunächst muss eine Quelle für das Server-Sent-Event definiert werden. Dies kann zum Beispiel eine PHP-Datei sein, die für die serverseitige Ausgabe sorgt und auf die reagiert werden soll:

1
var quelle = new EventSource("demo.php");

Über den Event-Handler onmessage oder die Methode addEventListener() geben wir eine Funktion an, die immer dann aufgerufen wird, wenn sich der Inhalt der Quelle (hier demo.php) verändert:

1
quelle.onmessage = demo;

Vorzuziehen ist die DOM-Standard-Variante mit addEventListener():

1
quelle.addEventListener("ping", demo, false);

Die Variante mit addEventListener() hat den Vorteil, dass neben der Funktion auch ein Event-Name (hier „ping“) angeben werden kann. Somit ist es möglich, dass eine Event-Quelle auf mehrere unterschiedliche Ereignisse reagiert.

Wie auf das Ereignis reagiert werden soll, wird in der Funktion festgelegt. Die einfachste Variante ist, den Inhalt der Quelle einfach auszugeben:

1
2
3
function demo(e) {
  document.getElementById("demoausgabe").firstChild.nodeValue = e.data;
}

Über .data hat man Zugriff auf den Inhalt der Event-Quelle. Statt den Inhalt der Quelle auszugeben, besteht die Möglichkeit, wesentlich komplexere Funktionen für die Reaktion auf das Ereignis zu definieren.

Server-Sent-Events: Vorgaben für die Event-Quelle

Die Event-Quelle muss einige Vorgaben berücksichtigen. So  ist auf die Verwendung des richtigen Content-Types zu achten, der per PHP wie folgt ausgegeben wird:

1
header("Content-Type: text/event-stream");

Außerdem muss der Inhalt UTF-8-kodiert sein. Da neben dem eigentlichen Inhalt ein Name für das Event festgelegt werden kann, sind folgende Feldbezeichnungen den Werten voranzustellen:

1
2
event: ping
data: Hier steht der Ausgabetext.

Das Feld event beschreibt den Event-Namen, der in der addEventListener()-Methode angegeben ist, data beinhaltet den auszugebenden Text. Sind mehrere Ereignisdaten definiert, werden diese mit zwei Zeilenumbrüchen voneinander getrennt. Hat man statt der addEventListener()-Methode den Event-Handler onmessage verwendet, kann man pro Event-Quelle nur auf ein Ereignis reagieren.

Das Server-Sent-Event wird unterstützt von Chrome ab Version 9, Firefox ab Version 6, Safari ab Version 5 und Opera ab Version 11. Der Internet Explorer ist – wie üblich – außen vor.

(dpe)

Denis Potschien ist seit 2005 freiberuflich als Kommunikationsdesigner tätig, seit Anfang 2010 im Kreativkonsulat in Iserlohn, einem Büro für Gestaltung und Kommunikation. Dort betreut er kleine und mittelständische Unternehmen ebenso wie kommunale Körperschaften und Organisationen aus Südwestfalen und dem Ruhrgebiet. Als Webdesigner und -entwickler gehören HTML5 und CSS3 zu seinen Kernthemen, weshalb er dazu 2013 ein Buch geschrieben hat. „Pure HTML5 und CSS3“ richtet sich an alle, die Vorkenntnisse haben, sich aber bisher mit HTML5 und CSS3 nicht oder nur am Rande beschäftigt haben.

Tags: , ,

18 Kommentare zu „HTML5 Server-Sent-Events: Per JavaScript auf Server-Requests reagieren
  1. AnyPotak am 19. Februar 2013 um 12:17

    “Da neben dem eigentlichen Inhalt ein Name für das Event festgelegt werden kann, sind folgende Feldbezeichnungen den Werten voranzustellen:

    1 event: ping
    2 data: Hier steht der Ausgabetext.”

    Wo / wie sollen diese “vorangestellt” werden? Wird nicht ganz klar (beim nicht-wissenden :-))

    • Denis Potschien am 20. Februar 2013 um 07:27

      Hallo,

      mit den Feldbezeichnungen sind die Begriffe vor dem Doppelpunkt gemeint, also “event” und “data”. Ich glaube, dies habe ich nicht verständlich genug ausgedrückt.

  2. Fumar Porros am 19. Februar 2013 um 15:51

    Also ich muss auch sagen: ich verstehe nur Bahnhof. Und zwar, weil hier nur sehr dürftige und unzureichende Informationen vermittelt werden. Nach dem Einleitungstext dachte ich noch: Naja, das gibt`s doch schon und nennt sich ganz allgemein Ajax. Nachdem ich dann mal Server-Sent gegooglet hatte, war klar, wo der Unterschied zwischen Server-Sent und den bisherige Ajax-Ansätzen liegt. Darauf wird hier aber überhaupt nicht eingegangen. Und mit den Code-Snippets kann auch kein Mensch was anfangen, wenn er – so wie ich – keine Ahnung hat. Inzwischen habe ich einige Quellen gefunden, die das wesentlich besser und mit Beispielen erklären – und das sogar auf deutsch…
    Fazit: Für mich ist dieser Artikel relativ nutzlos. Jemand, der die Thematik nicht kennt, versteht null und für alle anderen ist das hier dann wohl eher zum Gähnen…

    • Dieter Petereit am 19. Februar 2013 um 16:44

      HTML5 für Dummies ist nicht Vorgabe an den Autor gewesen.

      • Fumar Porros am 19. Februar 2013 um 17:14

        Ach so, bei dr.web werden nur noch Artikel für Profis geschrieben – Na denn…
        Dann muss ich mich allerdings erst recht fragen, was der Artikel soll, denn der kratzt doch gerade mal an der Oberfläche des Themas und hat absolut keine Tiefenwirkung…

        Übrigens: Gut zu wissen, das man ein Dummy ist, wenn man hier einen Artikel nicht gut findet oder gleich versteht – eine etwas arrogante Einstellung, aber okay… ^^

      • Adrian G. am 19. Februar 2013 um 19:16

        Fumar, da muss ich dir widersprechen. Meiner Meinung nach klingt es nicht arrogant was der Dieter hier schreibt.

        Man kann hier doch keine Artikel erwarten, die sich mit einem aktuellen/neuen Thema befassen und gleichzeitig das 1×1 des Javascripts & HTML erklären, damit es auch die letzte Omi am Laptop versteht, falls sie sich hier verirrt haben sollte.

        Für die Zielgruppe dieses Artikels, also jemanden der im Alltag mit Javascript zu tun hat und vielleicht noch nicht von Server-Sent-Events gehört bzw. sich noch nicht damit befasst hat, ist dieser Artikel völlig ausreichend um zu erfassen, welcher grundsätzlicher Unterschied zu AJAX besteht. Dazu sind diese Grund-Code-Schnipsel durchaus hilfreich.

        Wenn dieser Artikel und dieses Thema nun mein Interesse geweckt hat und für zuküftige Projekte interessant sein sollte, werde ich dieses Thema googlen und mich in aller Ausführlichkeit damit auseinandersetzen. Ich erwarte aber nicht es hier tun zu können, dafür ist diese Plattform nicht gedacht.

      • AnyPotak am 19. Februar 2013 um 19:22

        Also, ich fühle mich gar und gar nicht als “Dummie” was HTML5 angeht und auch nicht direkt aus dem Kommentar angesprochen, aber ich fragte mich wirklich, was der Autor meinte und daher diese Frage von mir. Es wird gar nicht klar wohin diese Felder müssen.

        Sicherlich, man kann wie Fumar Porros auch in anderen Quellen nachschlagen, aber Sinn eines solchen Artikels sollte doch auch das Überbringen von korrekten, hinreichenden und aufschlussreichen Informationen sein, oder?
        Oder warum hat dieser sonst “Tutorial-Charatker”?
        Sollte dieser nur Informativ sein, dann hätte viel weniger und ohne Beispiel gereicht…

        Btw. scheint Denis Potschien oft vieles als allg. bekannt und selbstverständlich zu halten, aber leider haben nicht alle sein Wissenstand.

      • CT am 20. Februar 2013 um 00:54

        Mehrwert scheint auch keine Vorgabe gewesen zu sein.
        Die Verwendungsmöglichkeiten, die in der Einleitung angesprochen werden, finden sich im Text nicht wieder. Man hätte den genausogut auf “googlet mal nach Server-Sent-Events” zusammenfassen können.

        Schade, bin deutlich bessere Artikel gewohnt.

    • AnyPotak am 19. Februar 2013 um 19:39

      Ich gehöre zu denen, die so etwas mit Ajax realisiert haben und diese Infos aus dem Artikel haben mir einen neuen Weg gezeigt, wie man ohne regelmäßiges Polling etwas aus dem Server bekommt – wenn dort fertig ist. Super Sache.

      Aber, auch für mich als fortgeschrittenen war es nicht ganz klar wie etwas von dem funktioniert. Wie sollte es dann bei weniger erfahrenen sein? Wahrscheinlich gar nicht verständlich. Und sicherlich ist das kein Thema für Anfänger.

      Leider kommt es in letzter Zeit hier öfters vor, dass ich nur den Anfang lese und dann direkt den Weiterführenden Link suche (der Glücklicherweise jetzt immer dabei ist…) – Wirklich Schade so ein “Verhalten”, den es steckt Arbeit hinter diesen Artikeln…

  3. Fumar Porros am 19. Februar 2013 um 20:07

    @Adrian G:
    Ich finde die Einstellung von Dieter schon arrogant. Ich bin ganz sicher kein Neuling, was Javascript und HTML5 angeht, und ganz bestimmt bin ich keine Omi, die sich hierher verirrt hat. Für mich ist dieser Artikel einfach ungenügend. Ich kann Deiner Meinung absolut nicht zustimmen: In anderen Artikeln habe ich Beispiele gefunden, die kurz und verständlich waren, hier werden mir lediglich Snippets geboten, die völlig unzureichend sind, um das Server-Sent wirklich zu erklären. Dabei wäre ein einfaches Beispiel mit HTML, JS und PHP nur wenige Zeilen lang…
    Auf den grundsätzlichen Unterschied zu Ajax wird überhaupt nicht hingewiesen. So what? Was soll der Artikel, wenn er nur ungenügende Information und/bzw. Erklärung bietet? Das es Server-Sent gibt, hätte man auch in einem Satz erwähnen können. Wenn man schon einen Artikel schreibt, dann richtig, finde ich…

  4. Jukka am 19. Februar 2013 um 20:36

    Ich hatte mich gestern noch mit einem Kollegen über das Thema unterhalten, daher kam mir der Artikel heute sehr recht und hat mir einen praktischen Einblick ermöglicht. Danke.

  5. Yves am 19. Februar 2013 um 22:01

    Hm, ohne mich jetzt weiter darüber informiert zu haben – ich gehe mal davon aus, dass die Serverseite eine normale Ausgabe produziert, aber nach jedem einzelnen Event verzögert und sowas wie Flush() aufruft. Der Client wartet dann wieder auf mehr Daten, bis zum nächsten Event, als wäre die Verbindung extremst lahm.

    Die üblichen Timeouts des Browsers werden hier wahrscheinlich nicht zutreffen, sonst könnte man ja nicht besonders lange auf Ereignisse warten.

    Über HTTP-Proxys dürfte dieses Verfahren kaum funktionieren, da die ja immer die ganze Antwort zwischenspeichern, ggf. auf Pinsel und Farben (vulgo Malware) prüfen und dann vollständig weiterleiten.

    Falls es nicht so ist, hat der Artikel leider nicht viel gebracht, außer dass ich jetzt weiß, dass es irgendsowas gibt, und erstmal suchen muss. Was ich vermutlich auch so getan hätte.

  6. Denis Potschien am 20. Februar 2013 um 07:31

    Der Artikel stößt ja auf sehr unterschiedliches Echo. Falls ich an der ein oder anderen Stelle unverständlich erklärt haben sollte, bitte ich um Entschuldigung. Auf eine Frage habe ich weiter oben (erster Kommentar) geantwortet.

    Wenn es weitere konkrete Unklarheiten gibt, gehe ich da gerne drauf ein.

  7. Martin Grulich am 20. Februar 2013 um 08:32

    Wo liegt denn jetzt der Vorteil gegenüber zyklische schon Ajax-Requests, die im Grunde das gleiche tun. Denn als ich das ganze gestern getestet habe, machte der Browser nichts anderes als alle x Sekunden eine Abfrage. Den einzigen Vorteil den ich sehe ist wirklich das Reagieren auf unterschiedliche Events, aber auch das kann ich mit Ajax-Requests lösen, wenn auch mit ein wenig mehr Code.

    • AnyPotak am 21. Februar 2013 um 02:00

      Bei einer Lösung mit Ajax muss ma selbst dafür sorgen, dass der Client regelmäßig beim Server nachfragt ob da etwas Neues zum Empfangen gibt. Das verursacht viel Overhead. Bei diesem Verfahren übernimmt der Browser selbst die Nachfrage und wenn was da ist wird vom Server quasi automatisch gesendet / empfangen.
      Hier noch ein Paar gute Infos dazu: http://stackoverflow.com/questions/9397528/server-sent-events-vs-polling

  8. Jannik am 12. März 2013 um 09:28

    Was mir ein bisschen an dem Artikel fehlt:

    * Muss das PHP-Skript dauernd laufen ( while(1) { /* … */ } )
    * Falls nicht: ist das dann einfach ein Ajax-Klon?
    * Falls doch: Sollte man die Probleme mit vielen offenen Verbindungen ansprechen (die z.B. den Apache sofort killen)? Und werden die Nachrichten dann immer einfach untereinander geschrieben? Was ist mit Zeilenumbrüchen und der unsauberen Trennung zwischen den Nachrichten?

    kein Trolling:
    @ Dieter Petereit
    es ist amüsant, solch einen relativ herablassenden Kommentar hier zu lesen “HTML5 für Dummies”, wenn der Artikel doch im Grunde so etwas ähnliches ist:
    Es wird erklärt, dass es Server-Sent-Events gib, wie man Events in JavaScript registriert (JavaScript für Dummies) und wie man HTTP-Header im PHP ausgibt (PHP für Dummies).
    Der nicht-für-Dummies-Teil wäre gewesen, den technischen Hintergrund dahinter zu erklären, was denn genau der praktische und theoretische Unterschied zu Technologien wie Websockets und AJAX ist.

    @ Denis Potschien:
    Die Kritik ist nicht gegen den Artikel gerichtet. Ich persönlich habe kein Problem, wenn bei jedem Artikel nochmal das addEventListener() zusammengefasst ist, allerdings, finde ich, ist der Artikel auf der technischen Seite etwas dünn.
    Die Dummies-Kritik ist nur gegen den unverschämten Kommentar gerichtet..

Ein Kommentar? Schön!

Wir freuen uns immer über Leser, die durch nützliche und konstruktive Beiträge zum Thema eine Diskussion anstoßen oder den Artikel mit weiteren Informationen anreichern. Alle Kommentare werden in diesem Sinne moderiert. Zum Kommentar-Fairplay gehört für uns auch der Einsatz von rel="nofollow". Bitte verwenden Sie zudem als Namen weder eine Domain noch ein spamverdächtiges Wort. Vielen Dank!