Im ersten Teil der HTML5-Serie konnten Sie alles über neue Präsentationsformen im multimedialen Bereich lesen. Im zweiten Teil beschäftigten wir uns mit den neuen Möglichkeiten zur Datenaufbereitung sowie zur Verknüpfung von Online-Diensten und lokalen Anwendungen. Im dritten Teil soll es nun um neue Methoden der Datenübertragung gehen.
Die Kommunikationswege der Web-Browser waren schon immer schwierig zu steuern. Für die Ausführung von Web-Dokumenten nutzen die Browser normalerweise eine "Sandbox": Die Web-Dokumente werden quasi vom Rest des Systems abgeschirmt. Damit werden größeren Schäden auf dem lokalen Rechner, dem Client, verhindert. Es ist kaum möglich, Schädlinge aus dem Netz mit nur einem Klick auf die Gesamtheit der stationär gespeicherten Daten loszulassen. Entwickler beschweren sich schon lange über diese Restriktionen. Sie wollen die zahlreichen Möglichkeiten nutzen, die sich ihnen böten, wenn der Browser mehr sei als "nur" ein Zugangsort zum WWW wäre. Gerade AJAX-Programmierer sind mit üblichen Browser-Restriktionen unzufrieden und fordern, die Zugriffsregeln zwischen "Sandbox" und Browser zu lockern.
Mit HTML5 soll sich der Blick auf das digitale Kommunikationsverhalten grundlegend ändern - zugunsten der Entwickler. Die eisernen Gesetze sollen jedoch weitestgehend ohne Kollateralschäden aufweichen können. Die Devise lautet: flexiblere Technologie bei gleich bleibenden Sicherheitsstandards.
Die Modelle und Methoden, die HTML5 anbringt, dürften den meisten Programmierern bekannt vorkommen - sind sie doch weitestgehend Erweiterungen bereits bekannter Ideen. So setzen beispielsweise GUI-Entwickler häufig auf Schaltflächen und Reiter, um Aktionen innerhalb eines Codes hin- und herzuschieben. Diese Listener genannten Seitenelemente befinden sich zwischen den Aktionen im dauerhaften Wartezustand auf die jeweils nächste Aktion. HTML5 trägt das Konzept weiter und schaltet verschiedene Websites über einen Tunnel zusammen, um Code untereinander auszutauschen. Somit läuft nicht mehr jede Website in ihrer eigenen "Sandbox". Die "Sandboxen" werden dafür aber nicht miteinander verschmolzen, sondern kommunizieren gleichzeitig über denselben Kanal.
Komplexität verringern
Programmierer, die ständig bemüht sind, die Gefahr von Webattacken wie Cross-Site-Scripting möglichst gering zu halten, erhöhen mit jedem zur Gefahrenabwehr entwickelten Hack auch die Komplexität des Codes sowie den Netz-Traffic. Einige Websites schalten serverseitig einen Proxyserver vor, um die Probleme auszuschalten. Die neuen HTML-Spezifikationen greifen den Entwicklern nun unter die Arme. Es soll keine Geschwindigkeitseinbußen durch komplexeren Code mehr geben.
Der erste Bereich, in dem die neu entstandenen Möglichkeiten zum Einsatz kommen könnten, ist möglicherweise die Werbung. Dort wird bereits länger versucht, durch das Zusammenspiel verschiedener Site-Ebenen mehr Aufmerksamkeit beim Anwender zu erzeugen. Die Verlinkung mehrerer Prozesse untereinander macht nun eine Interaktion zwischen Widgets, RSS-Feeds und anderen Datenkanälen verschiedener Fenster möglich.
Wie genau das aussehen kann, zeigen unter anderem Yahoo Pipes-Mashups, die verschiedenste Quellen miteinander rekombinieren. In diesem Fall bewerkstelligt der Server die meiste Arbeit, während HTML5 dem Client nur einen kleinen Teil der Verantwortung zubilligt. Yahoo Pipes ist voller Mashups, die RSS-Feeds in interaktive Karten und andere Dienste übertragen. So verbindet eines die Filmkritiken von einer Website mit den entsprechenden Kinotrailern aus einem anderen Angebot.
Von Webdokumenten zu Web-Applikationen
Das ursprüngliche Konzept eines Webdokuments sah ein Dokument mit Wörtern und Bildern vor - eingerahmt in ein einziges Rechteck. Im Laufe der Zeit wurde das große Rechteck zwar in viele kleine, mit anderen Hintergrundfarben versehene Rechtecke unterteilt - in allen gab es aber nach wie vor Wörter und Bilder. Da war nicht viel zu spezifizieren. Heute sind Webdokumente dank AJAX-Funktionen eher als Software einzustufen - und Software lebt. Doch das Leben in den Browserfenstern sollte nach dem Willen vieler Programmierer nicht auf jeweils ein Fenster oder alle Fenster eines Webangebots beschränkt bleiben. Warum nicht die Box mit den Inhalten und die Box mit der Werbung seitens Google AdWords miteinander verknüpfen? Oder warum nicht noch mehr Nutzen aus Blog-Widgets ziehen, um den Besuchern Wettervorhersage, Spielstände oder Kinozeiten anzuzeigen?
Datentransfer über mehrere Dokumente
Die Köpfe hinter HTML5 brechen eine Lanze für die Idee des Datentransfers über mehrere Dokumente hinweg. Die angesprochenen Rechtecke bauen einen Kommunikationskanal auf, indem sie mittels Quellcode Listener erstellen. Diese Listener warten auf Nachrichten anderer Rechtecke oder verschicken selbst Nachrichten, ganz ohne zentralen Server. Die verantwortliche API sorgt dafür, dass der Transfer auf bestimmte Domains beschränkt wird. Es ist nicht möglich, Nachrichten an alle potenziellen Listener zu senden. Der Entwickler legt fest, welche Fenster und Dokumente angesprochen werden. Für einen dauerhaften Austausch legt er Zweiwegekanäle an.
Die Listener-Spezifikation ist noch in der (instabilen) Betaphase, wird aber von nahezu allen Browsern schon unterstützt (Chrome, Firefox, IE, Opera, Safari). Da jede Software mit einer ähnlichen Interlayer-Kommunikation arbeitet, ist es nur eine Frage der Zeit, bis sich das Prinzip auch bei den Entwicklern auf breiter Ebene durchsetzt. Wer seinen Browser testen möchte, kann das hier tun.
Ressourcen-Sharing
Nachrichten zu verschicken ist nicht der einzige Weg, Informationen zwischen Websites auszutauschen. Die API für "Cross-Origin Resource Sharing" (cors) lockert die Kontrolle über AJAX-Befehle und erlaubt auch außerhalb der Home-Domain den Zugriff. Eine Website kann so eine Liste erlaubter Ziele festlegen, und die XMLHttpRequest-Anfragen sollten funktionieren. Die Informationen darüber stehen im Header des HTML-Dokuments. Damit der Server sie verarbeiten kann, muss er deshalb rekonfiguriert werden - eine Aufgabe für den Administrator, nicht für den Entwickler:
Access-Control-Allow-Origin: http://infoworld.com [9] Access-Control-Max-Age: 10000 Access-Control-Allow-Methods: PUT, DELETE
Dieser Eintrag erlaubt es einer Website, zusätzliche Daten von infoworld.com zu holen und anzuzeigen, die maximal 10.000 Sekunden alt sind.
WebSockets
Wenn AJAX-Befehle lange brauchen, um vollständig ausgeführt zu werden, gehen sie meist mit einem Time-out zu Ende. Diese Fehlermeldungen wären für Aufgaben wie das Einsammeln der aktuellen Nachrichten ja noch akzeptabel - für interaktive Websites, die ein schnelles Server-Pinging voraussetzen, ist das jedoch nicht zu empfehlen. Um nicht ständig in regelmäßigen Zeiträumen einen Ping an den Server senden zu müssen, um Informationen aktualisieren zu können, wurde das auf TCP basierende WebSocket-Protokoll erfunden, das eine bidirektionale Verbindung zwischen Webanwendung und Web(Socket)-Server herstellt. Wo TCP Daten nur dann aktualisiert, wenn ein erneuter Ping ausgeführt wird (Pull-Verfahren), hält WebSockets die Verbindung die ganze Zeit aufrecht und kann neue Daten in Echtzeit überspielen (Push-Verfahren). Mit HTML5 wird die WebSocket-API an den Quellcode angebunden. Chrome, Firefox, Opera und Safari unterstützen WebSockets bereits - die meisten Webserver hingegen noch nicht, weshalb die Möglichkeiten keinesfalls schon nutzbar wären. Ein Beispiel für ein bereits entsprechend eingerichtetes WebSocket-Gateway-Angebot ist Kaazing.
Aber auch eine WebSocket-Verbindung ist nicht ewig stabil, von ihren Sicherheitsproblemen ganz zu schweigen. So haben Google und Mozilla die WebSocket-Unterstützung in ihren Browsern derzeit abgeschaltet, nachdem es Forschern gelungen war, über WebSockets Malware in den Browser-Cache zu laden. Die von den Wissenschaftlern vorgeschlagene Verbesserung des Browser-Codes an dieser Stelle wird von den Herstellern gerne angenommen. Bereits jetzt lässt sich die WebSocket-Unterstützung im Firefox mit wenigen Handgriffen wieder einschalten - wenn auch zunächst nur zu Testzwecken. Es wird aber nicht lange dauern, bis sich das Protokoll mit Hilfe von HTML5 auf breiter Front durchsetzt.
Server-sent Events
Dass der Client Daten vom Server abholen kann und sich mittels WebSockets Informationen in beide Richtungen transportieren lassen, wissen wir nun. Fehlen noch die server-sent events, die es dem Server erlauben, einseitig und ohne Rückfrage beim Client Daten zu versenden und Funktionen auszuführen. Dazu bedarf es erst eines EventSource-Objekts, das die Domain anzeigt. Im zweiten Schritt der Implementierung wird eine Funktion registriert, mittels der die Events im "If"- und "When"-Modus verarbeitet werden. Dazu braucht es keinerlei offener Sockets oder ständiger Anfrage bei einem anderen Server. Gerade auf mobilen Geräten sind die server-sent events sinnvoll, um Energie zu sparen.
Ein einfacheres Web
Sowohl Web-Entwickler als auch ISPs dürften von den verbesserten Kommunikationskanälen profitieren. Der Bedarf an massivem Datenverkehr sinkt und die Geschwindigkeit der Web-Angebote steigt. Lediglich die Gretchenfrage nach der Sicherheit bleibt. Diese liegt in der Verantwortung der Serverbetreiber, da die vorgestellten Features von der Anwenderseite aus nicht beeinflusst werden können. Unterstützt ein Web-Server einige oder alle, hat der Nutzer dies mitzutragen - unterstützt er sie nicht, ebenfalls. Vielleicht ändert sich das, sobald das Missbrauchspotenzial deutlich aufgezeigt wird - die Hacker stehen sicherlich in den Startlöchern. (mje)
Dieser Beitrag basiert auf einem Artikel unserer Schwesterpublikation Computerwoche. Grundlage des Artikels bildet eine Veröffentlichung von Peter Wayner in der amerikanischen IDG-Publikation Infoworld.