Zum Protokoll

Was AJAX-Entwickler über Web Services wissen sollten
Kommentare

AJAX-Clients kommunizieren mit dem Server auf der Basis von Web-Services-Protokollen. Dabei werden verschiedene auf http basierende Formate wie z.B. REST, JSON und SOAP verwendet. Dieser Artikel gibt einen Überblick über die
wichtigsten Protokolle und ihre Eigenschaften und für welchen Einsatzzweck sie sich am besten eignen.

Web Services sind ein Sammelbegriff für Operationen, die über Netzwerke aufgerufen werden können. Da er Ende des Jahres 2000 im Zusammenhang mit dem SOAP-Protokoll geprägt wurde, wird er häufig auch mit SOAP gleichgesetzt, obwohl es einige zum Teil deutlich ältere Protokolle und Verfahren für „Operationen, die über Netzwerke aufgerufen werden können“ gibt. Wer klassische Webanwendungen implementiert, kümmert sich normalerweise nicht um die Daten, die tatsächlich über die Netzwerkverbindung übertragen werden. Interessant sind vor allem die Nutzdaten, typischerweise HTML-Tags, die Cookies und die Meta-Informationen, die zur Steuerung des Caches auf dem Client verwendet werden. Insbesondere das HTML-Element

bringt einiges an Funktionalität mit sich. Auch hier wird weit oberhalb der Protokollebene implementiert, indem -Elemente mit all ihren möglichen Optionen verwendet werden, um Daten an den Server zurückzusenden. Die HTML-Funktionalität, die in den Browsern heute zur Verfügung steht, sieht außer dem Laden einer Seite und evtl. dem Nachladen von dynamisch hinzugefügten Elementen keine weitere Interaktion mit dem Server vor. Mit AJAX ändert sich an dieser Situation einiges, und deshalb lohnt sich ein Blick auf die Protokollebene, die über das XMLHttpRequest-Objekt verfügbar wird. Durch ein besseres Verständnis erreicht man auch eine höhere Sicherheit bei der Bewertung der möglichen Implementierungen und der notwendigen Architektur. Microsoft hat 1999 mit dem ActiveX-Control, das unter dem Namen „Microsoft.XMLHTTP“ mit dem IE 5.0 verfügbar wurde, hier eine zusätzliche Möglichkeit geschaffen, auf der tiefer liegenden Ebene des http-Protokolls eine weitere Verbindung zum Server aufzubauen. Glücklicherweise wurde diese Idee auch von anderen Browsern aufgenommen und umgesetzt, denn die dadurch entstehenden Möglichkeiten sind zu fantastisch, als dass man sie wegen irgendwelcher Prinzipien oder Weltanschauungen (Kennen Sie „Browser Wars“?) nicht umsetzen sollte. Inzwischen ist aus den existierenden, sehr kompatiblen Implementierungen des XMLHttpRequest-Objekts ein Standard entstanden.

Das http(s)-Protokoll

Das http-Protokoll ist die Grundlage der Kommunikation in AJAX-Anwendungen. Wenn mit dem XMLHttpRequest-Objekt kommuniziert wird (der Name des Objekts deutet es bereits an), müssen die speziellen Eigenschaften und Vorgehensweisen dieses Protokolls berücksichtigt werden. Die weiteren Protokolle, wie z.B. REST, basieren darauf und nutzen die im http-Protokoll definierten Möglichkeiten. Der Mechanismus des http-Protokolls ist recht einfach, Texte und Nutzdaten werden über einen TCP/IP-Port ausgetauscht. Das trifft auch auf binäre Dateien wie z.B. GIF-Dateien zu. Jeder Nachrichtenaustausch besteht aus einem Header, der flexibel um Angaben erweitert werden kann, und aus einem optionalen Body für die Nutzdaten. Initiiert wird eine http-Übertragung immer vom Client, in unserem Fall dem Browser, und der Server antwortet über die gleiche Verbindung (Listing 1).

Listing 1
-------------------------------------------------------------------------
GET /mathertel.css HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*
Accept-Language: de,en;q=0.5
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) 
Host: www.mathertel.de
Proxy-Connection: Keep-Alive

Die übermittelten unsichtbaren Zeichen am Zeilenende sind hier in spitzen Klammern hinzugefügt, denn sie spielen für die Auftrennung der Bestandteile der Übertragung eine wesentliche Rolle. Jede Übertragung zum Server (auch die in Listing 1), wird durch eine Methode, dem URL und der Angabe des Protokolls in der ersten Zeile eingeleitet. Mit der Methode wird angegeben, was mit der durch den URL definierten, angeforderten Ressource zu geschehen hat. Im Beispiel wurde die GET-Methode verwendet, die prinzipiell keine weiteren Nutzdaten verwendet, sondern für die Abfrage von meist statischen Daten verwendet wird, die unter einem URL verfügbar sind. Typische Beispiele sind HTML-Dateien, Grafiken oder referenzierte JavaScript-Dateien. Nach der obligatorischen Leerzeile, die den Header abschließt, können Nutzdaten folgen, die an den Server übermittelt werden. Die typische Situation dafür ist das Absenden eines ausgefüllten HTML-Formulars mit der POST-Methode. Der ersten Zeile folgen die Header-Informationen in Form von Merkmal und Wert-Paaren, wie z.B. der optionalen Zeile mit der Angabe der Länge der Nutzdaten und dem übermittelten Datentyp der Nutzdaten (Listing 2).

Listing 2
---------------------------------------------------------------------
POST /AJAXEngine/S03_AJAXControls/ValidatorDemo.aspx HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*
Referer: http://www.mathertel.de/AJAXEngine/S03_AJAXControls/ValidatorDemo.aspx
Accept-Language: de,en;q=0.5
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;.NET CLR 1.1.4322) 
Host: www.mathertel.de
Content-Length: 195
Proxy-Connection: Keep-Alive
Pragma: no-cache
Cookie: jcl.view=Examples
__VIEWSTATE=%2FwEPDwUKMTA5OTIyNzA5NmRkmSlC7ZGuxBkiZb3FLxjBpA2nfXc%3D&NAME_IN=Matthias&EMAIL_IN=mathertel@hotmail.com&__EVENTVALIDATION=%2FwEWAwKBlvTdAgKG7u7IBQLdztHVCfwPc2ly3hyLE0QxlLbqx1UYmQ%2BQ

Die Antwort des Servers ist ebenfalls Text und weist eine hohe Ähnlichkeit zu einer Abfrage auf (Listing 3). In der ersten Zeile wird die Qualität der Antwort als Statuscode zurückgegeben. 200 OK steht dabei für eine fehlerfreie vollständige Übertragung. Dann folgen wieder einige Headerzeilen, in denen typischerweise auch die Länge der Nutzdaten beschrieben ist, die unmittelbar nach der Leerzeile beginnen. Bilder werden ab diesem Punkt binär übertragen.

Listing 3
--------------------------------------------------------------------
HTTP/1.1 200 OK
Content-Length: 6833
Content-Type: text/css
Last-Modified: Fri, 14 Jul 2006 20:21:48 GMT
Accept-Ranges: bytes
ETag: "c3801b2283a7c61:706"
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Sat, 15 Jul 2006 20:02:51 GMT
/* -- Stylesheet for http://www.mathertel.de and AJAX Engine Example WebSite -- */

body,td,th,button {font-family:Tahoma,Helvetica, Arial; font-size:10pt;color:black; }
body { margin:4px; background:white; }

Eine weitere grundlegende Eigenschaft dieses Protokolls ist die zustandslose Art der Anfrage an einen Server. Das Protokoll kennt keine Querverweise zu anderen Abfragen, noch benötigt es Informationen über den Client auf Serverseite. Die Abfragen selbst beschreiben sich immer vollständig. Bei der Verwendung des XMLHttpRequest-Objekts zur Kommunikation ist die Angabe der Methode zwingend notwendig. In vielen Fällen muss auch der Datentyp der zu übertragenden Daten gesetzt werden. Mit der Variante des https-Protokolls, das die gleichen Daten wie das http-Protokoll austauscht, existiert auch die Möglichkeit der verschlüsselten Übertragung. Die Details dieser Verschlüsselung und der typische Verlauf, der zum Austausch der notwendigen Zertifikate benötigt wird, werden glücklicherweise vollständig vom XMLHttpRequest-Objekt abgenommen. Tipp: Beobachten kann man diese Übertragungsdetails z.B. mit dem kostenlosen Werkzeug Fiddler für Windows. Es richtet sich als http-Proxy im System ein und protokolliert alle Datenübertragungen mit. Die aktuelle http-Spezifikation von 1999 ist hier zu finden.

Cross-Site Scripting (XSS) Unter Cross-Site Scripting versteht man den Zugriff einer Webapplikation von einem Server auf die Daten einer anderen Webapplikation auf einem anderen Server. Zugriffe dieser Art wurden in der Vergangenheit oft für DoS-Attacken (Denial of Service) und Security Leaks ausgenutzt (siehe auch hier).

Die Einschränkung des XMLHttpRequest-Objekts besteht darin, dass eine Kommunikation von einer geladenen Seite aus nur bei Verwendung des gleichen Protokolls und zum gleichen Server möglich ist. Ein Anwender sollte anhand der Adressleiste des Browsers erkennen können, mit welchem Server er aktuell kommuniziert. Diese in Zeiten des Phishings nachvollziehbare Anforderung wird allerdings bei der Anzeige von Bildern und dem Nachladen von Skripten nicht ganz eingehalten. Unterschiedliche Protokolle werden ggf. dem Benutzer als Meldung angezeigt und Ressourcen anderer Server gerne ausgefi ltert, um z.B. Werbung zu unterbinden.

Tipp: Wenn Sie eine AJAX-Anwendung konzipieren, dann verlassen Sie sich nicht darauf, dass Sie auf Ressourcen anderer Server direkt zugreifen können. Die Chance: Eine Applikation auf einem Server kann keine AJAX-Applikation auf Clients ausrollen, die eine DoS-Situation auf einem anderen Server zur Folge hat. Jede AJAX-Anwendung muss deshalb auf dem zugehörigen Server ein Gateway auf die Ressourcen des anderen Servers implementieren. Dies ermöglicht gleichzeitig das Caching und die Konsolidierung der Daten von anderen Servern auf dem Server der AJAX-Anwendung.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -