• < blättern >

4.2 Aufbau von HTTP-Nachrichten

Den Kern einer AJAX-basierten Anwendung stellt die Verwaltung von nebenläufigen HTTP-Transaktionen dar, die vom Webbrowser initiiert werden, um neue Daten vom Server zu erhalten. Viele der hier gezeigten Techniken basieren auf bestimmten Eigenschaften von HTTP, deren Kenntnis eine Voraussetzung für das Verständnis der Funktionsweise von AJAX ist.

Abb 25 Schematischer Ablauf einer HTTP-Transaktion

Eingangs dieses Kapitels wurde bereits der grundsätzliche Ablauf von Transaktionen im Client/Server-Modell erläutert, den Schematischer Ablauf einer HTTP-Transaktion noch einmal bildlich darstellt.

Der vom Browser gesendete Request gelangt zum Server und wird dort verarbeitet. Das Ergebnis dieser Operation wird anschließend in einer HTTP-Response dem anfragenden Client mitgeteilt. Anfrage und Antwort unterscheiden sich nur geringfügig im syntaktischen Aufbau, wie Schematischer Aufbau von HTTP-Nachrichten zeigt.

Abb 26 Schematischer Aufbau von HTTP-Nachrichten

HTTP-Request

Deutlich zu erkennen ist die unterschiedlich aufgebaute erste Zeile der beiden Nachrichten. Im HTTP-Request gibt diese Zeile die auszuführende Aktion an und benennt die Ressource, auf die sich diese Aktion bezieht. Der dritte Eintrag dient zur Identifikation des Protokolls HTTP und der verwendeten Version, hier also Version 1.1. In diesem Beispiel wird also ein GET-Request bezogen auf die Ressource „/webhp?complete=1“ des kontaktierten Servers gesendet. Auf die Startzeile des Requests folgt eine Reihe von Header-Feldern in fast beliebiger Reihenfolge, die den Request genauer beschreiben. Jedes Header-Feld besteht aus einem Namen und einem Wert, die durch einen Doppelpunkt voneinander getrennt sind. Die Werte gleichnamiger Header-Felder können in einem Header zusammengefasst werden, indem sie mit einem Komma getrennt werden. Die wichtigsten Header-Felder in diesem Request sind:

HTTP-Response

Die Antwort des Servers beginnt mit einer Statuszeile, die neben der Identifikation des Protokolls und der Versionsnummer einen dreistelligen Statuscode sowie eine textuelle Beschreibung des Ergebnisses enthält. Die erste Ziffer des Statuscodes gibt Aufschluss über die Art der Meldung, damit Clients auch Antworten mit unbekannten Statuscodes korrekt verarbeiten können. Die Tabelle Statuscodes in HTTP zeigt die Bedeutung der Statusklassen, wie sie in RFC 2616 RFC 2616: Hypertext Transfer Protocol -HTTP/1.1 definiert wurde. Die textuelle Beschreibung nach dem Statuscode ist rein informativ und kann z. B. einem Benutzer angezeigt werden, wenn der Browser die genaue Bedeutung des Statuscodes nicht kennt. Die am häufigsten angezeigten Meldungen sind vermutlich die Fehlercodes 403 und 404 mit ihren textuellen Entsprechungen „Forbidden“ und „Not Found“.

Tabelle 2: Statuscodes in HTTP

Code	Beschreibung
1xx	Kennzeichnet eine vorläufige Antwort zur Information über den Status der Bearbeitung. Die Transaktion wird mit einer 1xx-Antwort nicht beendet.
2xx	Die Anfrage wurde erfolgreich bearbeitet und das Ergebnis ist der Antwort beigefügt.
3xx	Die angefragte Ressource ist nicht auf dem Server verfügbar, sondern kann von einer anderen Quelle bezogen werden, die in der Antwort benannt ist.
4xx	Die Anfrage war fehlerhaft und kann deswegen nicht bearbeitet werden.
5xx	Bei der Verarbeitung der Anfrage ist auf dem Server ein Fehler aufgetreten, der nicht unmittelbar mit dem Request zusammenhängt.

Antworten mit einem Statuscode zwischen 100 und 199 stellen eine Besonderheit in HTTP dar, da sie die Transaktion nicht beenden. Sie können beispielsweise bei einem Datei-Upload verwendet werden, um vor der Übertragung einer Datei zu signalisieren, dass die Operation Erfolg haben wird. Dadurch kann der Client das Senden umfangreicher Daten verzögern, bis entweder eine Antwort mit dem Statuscode 100 als Aufforderung zum Fortsetzen der Sendeoperation oder eine entsprechende Fehlernachricht empfangen wurde.

Der Statuszeile der Antwort folgt wie bei der Anfrage eine Reihe von Header--Feldern, die weitere Informationen über das Ergebnis der Operation enthalten, -beispielsweise zur Steuerung des Seiten-Cache im Browser. Den wichtigsten Teil der Antwort stellen in den meisten Fällen aber die Inhaltsinformationen dar, die nach dem Block mit den Header-Feldern folgen und mit einer Leerzeile davon getrennt werden. Abhängig von der Art der Anfrage und der Serverkonfiguration kann es sich bei den Inhaltsinformationen um beliebige Daten handeln, solange diese den in der Anfrage spezifizierten Eigenschaften entsprechen (Anfrage-Header Accept, Accept-Language, Accept-Encoding und Accept-Charset).

Damit der Client die in der Antwort enthaltenen Inhaltsinformationen verarbeiten kann, werden der Medientyp, die verwendete Sprache und die Zeichenkodierung im Header-Bereich beschrieben. Die dazu verwendeten Felder entsprechen in ihrer Namensgebung den Header-Feldern aus der Anfrage, mit denen der Client seine Präferenzen ausgedrückt hat. Die folgende Übersicht zeigt die wesentlichen Header-Felder zur Beschreibung der Inhaltsinformationen einer HTTP-Antwort:

Zustandsverwaltung mit Cookies

Als zustandsloses Protokoll bietet HTTP keine eingebaute Unterstützung für transaktionsübergreifende Sessions zwischen Browser und Server. Das bedeutet, eine webbasierte Anwendung ist selbst für die Erzeugung und Verwaltung persistenter Zustandsinformationen verantwortlich. Die Synchronisation zwischen Client und Server erfolgt mit Hilfe einer Erweiterung des Protokolls HTTP, die zusätzliche Header-Felder zur Übertragung Session-spezifischer Daten erlaubt (siehe Persistent Client State - HTTP Cookies). Ursprünglich von der Firma Netscape entwickelt, wird diese Protokollerweiterung von praktisch allen modernen Browsern unterstützt. (Cookies wurden später als RFC 2109 RFC 2109: HTTP State Management Mechanism standardisiert; die dort vorgenommenen Änderungen haben sich aber nicht alle durchgesetzt. Ein weiterer Versuch der Weiterentwicklung durch Standardisierung, RFC 2965, hat noch weniger praktische Bedeutung.) Die Funktionsweise des Cookie-Mechanismus illustriert Verwendung von Cookies für persistente Zustandsinformationen.

Das Bild zeigt die Verwendung der Header-Felder Set-Cookie und Cookie zum Übermitteln von Zustandsinformationen. Zu Beginn der Sitzung wird ein Cookie in einer Antwortnachricht des Servers mit dem Headerfeld Set-Cookie gesetzt. Der Wert des Headers besteht aus einem Bezeichner für die Zustandsvariable, gefolgt von einem Gleichheitszeichen und dem zu speichernden Wert. Der Browser, der diese Antwort erhält, speichert nach einer Sicherheitsprüfung den Wert unter dem angegebenen Namen, um diese (Name und Wert) in folgenden Requests im Headerfeld Cookie wieder an den Server zu senden.

Neben dem Namen und dem aktuellen Wert des Cookie kann der Server im -Headerfeld Set-Cookie noch weitere Parameter angeben, mit denen sich das Verhalten des Clients genauer steuern lässt. Die folgende Übersicht zeigt die in der ursprünglichen Spezifikation von Netscape vorgesehenen Parameter mit ihrer Bedeutung, wie sie auch heute noch in webbasierten Anwendungen verwendet werden.

Abb 27 Verwendung von Cookies für persistente Zustandsinformationen

Die Syntax der oben angeführten Parameter entspricht weitgehend der in RFC 2616 RFC 2616: Hypertext Transfer Protocol -HTTP/1.1 definierten Syntax für Parameter in Headerfeldern. Der Parameter expires nimmt hier eine Sonderrolle ein, da der angegebene Wert entgegen der Konvention nicht in Anführungszeichen eingeschlossen wird.

(RFC 2965 sieht noch weitere Parameter und neue Headerfelder vor, die in der Praxis allerdings eher geringe Bedeutung haben. Um größtmögliche Kompatibilität mit bestehenden Browsern zu wahren, sollte sich eine Anwendung nicht auf die -Existenz von Parametern verlassen, die nicht in der obigen Liste aufgeführt sind. Eine Ausnahme stellt der Parameter Version dar, der in der ursprünglichen Cookie-Spezifikation nicht vorgesehen ist. In der standardisierten Variante ist die Verwendung dieses Parameters vorgeschrieben, so dass mit dieser Angabe eine Unterscheidung zwischen beiden Versionen der Spezifikation möglich ist.)

In AJAX-basierten Anwendungen nimmt die transaktionsübergreifende Synchronisierung von Zustandsinformationen naturgemäß eine bedeutende Stellung ein, da hier zahlreiche kurzlebige Interaktionen zu einer länger andauernden Sitzung zusammengefasst werden. Wie bei anderen HTTP-Anfragen von Browsern werden auch bei XMLHttpRequest Cookies gesendet und Set-Cookie-Header aus der Antwort ausgeführt.

Anders als bei Dokumentformaten, DOM-Unterstützung oder CSS ist für den Austausch von Cookies kein Trend zur Implementierung des offiziellen Standards RFC 2965: HTTP State Management Mechanism zu erkennen. Statt dessen basieren die meisten Anwendungen auf der ersten von Netscape veröffentlichten Fassung, die damit den Rang eines Quasi-Standards erreicht hat.

HTTP-Transaktionen und AJAX

Das WWW in seiner ursprünglichen Form war als verteiltes Informationssystem konzipiert, das einen Zugriff auf entfernte Datenspeicher ermöglichte. Nachdem anfänglich vorwiegend statische Dokumente über das WWW bezogen wurden, die als Datei auf dem Serversystem verfügbar waren, wurde schnell deutlich, dass der Dienst von Anfang an so entworfen war, dass auch dynamisch erzeugte Objekte mit beliebigem Typ über HTTP befördert werden können. DHTML und Remote Scripting führten diese Entwicklung fort, indem die dynamische Veränderung von Dokumenten nun auch auf der Clientseite stattfand.

AJAX-Technologien führen diesen Ansatz fort, indem die Interaktivität ein stärkeres Gewicht bekommt. Anstelle einzelner HTTP-Transaktionen, die jeweils ein für sich isoliertes Dokument im Ganzen ausliefern, tritt nun die Übertragung von Informationshäppchen, die im Browser zu einem größeren - und dynamisch veränderlichen - Gesamtbild zusammengesetzt werden. In Anlehnung an Nebenläufige HTTP-Transaktionen in AJAX-basierten Anwendungen den veränderten Ablauf der Kommunikation zwischen Browser und Server in einer AJAX-basierten Anwendung.

Abb 28 Nebenläufige HTTP-Transaktionen in AJAX-basierten Anwendungen

Deutlich zu erkennen ist in diesem Beispiel die hohe Frequenz, in der HTTP-Requests ausgesendet werden. Moderne HTTP-Server und -Clients erleichtern diese Art der Kommunikation, indem TCP-Verbindungen für die Dauer der Transaktionsfolge geöffnet bleiben, anstatt für jede Anfrage einen neuen Transportkanal zu öffnen. Die Zuordnung der Transaktionen auf dem Server erfolgt am einfachsten mit dem zuvor erläuterten Cookie-Mechanismus, über den ein eindeutiger Sessionbezeichner ausgetauscht werden kann.

Weitere Methoden in HTTP

In den bisherigen Ausführungen wurde nicht unterschieden, welche Methode in der Startzeile von HTTP-Anfragen aufgeführt wird. Die am häufigsten verwendete HTTP-Methode ist GET . Die Semantik von GET schließt jedoch einen Seiteneffekt , also das Verändern des Serverzustands in einer Weise, die Rückwirkung auf den Benutzer hat, aus: Es gibt zu viele Fälle, in denen Systemkomponenten wie Browser oder Caches ohne weiteres Zutun des Benutzers entscheiden, ein GET auszuführen (besonders unangenehm ist das böswillige Unterschieben von automatisch verfolgten Links, wie z. B. aus IMG-Elementen; vgl. auch Intertwingly: SAJAX Still Unsafe und Intertwingly: Taking the unsafe GETs out of Rails).

Je nach auszuführender Aktion kann es daher angebracht sein, eine andere Methode als GET einzusetzen; insbesondere fallen Operationen wie das Abschicken von Bestellungen, die Aktualisierung von Datenbanken, das Hinzufügen von Dateien oder auch das Löschen von Ressourcen nicht in den Aufgabenbereich eines GET-Requests. Für diese Aufgaben stehen in HTTP weitere Methoden zur Verfügung, von denen einige auch in AJAX-basierten Anwendungen sinnvoll eingesetzt werden können:

Unabhängig davon, ob im konkreten Anwendungsfall PUT oder POST verwendet wird, haben beide Methoden über die u. U. passendere Semantik hinaus gegenüber GET den Vorteil, dass problemlos größere Mengen an Daten übertragen werden können. Jeder Web-Entwickler, der schon einmal vor der Entscheidung stand, ob in einem Formular POST oder GET verwendet werden soll, kennt dieses Problem: Während in einem POST-Request die Daten im Inhalt der Nachricht übertragen werden, fügt der Browser die Werte aus den Formularfeldern für einen GET-Request dem URI hinzu. Dies ist nicht nur unschön, sondern kann auch zu Problemen führen, wenn Browser oder Server eine feste Obergrenze für die Länge der Startzeile vorgeben.

Die Programmierschnittstelle von XMLHttpRequest bietet zahlreiche Möglichkeiten zur Modifikation des abzusetzenden HTTP-Requests. So kann die zu verwendende Methode beispielsweise in der Funktion open spezifiziert werden. Zwei weitere Parameter ermöglichen zudem die Angabe von Benutzername und Passwort, um eine Authentisierung beim Server zu ermöglichen. Versenden eines POST-Requests mit XMLHttpRequest und Versenden eines PUT-Requests mit XMLHttpRequest illustrieren die Verwendung von XMLHttpRequest mit den HTTP-Methoden POST und PUT zum Senden einer Datei an einen Server. Bei POST werden der Name und die zu speichernden Daten im Rumpf der HTTP-Nachricht übertragen, der an die Funktion send übergeben wird. Schließlich wird mittels setRequestHeader der Medientyp application/x-www-form-urlencoded gesetzt, um ein korrektes Parsieren der übertragenen Daten auf dem Server sicherzustellen. Bei PUT muss der Server Information über den Dateinamen aus dem Anfrage-URI ableiten (im Beispiel gibt der Client darüber hinaus den Content-Type als XML vor).

In beiden Fällen kann der Server erfolgreiche Anfragen mit den Antwortcodes 200 („OK“) oder 204 („No Content“) beantworten; 200 steht dabei für den Fall, dass in der Antwort noch eine beschreibende Ressource (z.B. ein HTML-Dokument zur Anzeige für den Benutzer) mitgeliefert wird, während 204 ein wortloses OK ist. Die Anfrage kann, wenn eine neue Ressource angelegt wurde, auch mit 201 („Created“) beantwortet werden (wie bei 200 mit einer Ressource in der Antwort).

_body="filename="+escape(_filename)+"&content="+escape(_text);
var req = new XMLHttpRequest();
req.onreadystatechange = handleStateChange;
req.open('POST', '/serverscript.php', true, username, password); 
req.setRequestHeader('Content-Type',
                     'application/x-www-form-urlencoded');
req.send(_body);

var req = new XMLHttpRequest();
req.onreadystatechange = handleStateChange;
req.open('PUT', '/path/' + escape(_filename), true, username, password); 
req.setRequestHeader('Content-Type',
                     'application/xml');
req.send(_text);

• < blättern >

Home • Über uns • Qualität • AGB • Impressum • Stadtlupe • Stellenangebote & Jobs

Die TEIA AG bietet Bücher, Lernprogramme, SCORM und kostenlose Online Kurse zu Microsoft-Anwendungen, Open Office, IT, Programmierung und Wirtschaft.
Zu fast allen Online Kursen können zudem Zertifkate oder Teilnahmebescheinigungen erworben werden.

Access 2002 •  Access 2003 Basis •  Access 2003 Prof. •  Access 2007 Basis •  Adobe GoLive •  Adobe Photoshop •  AJAX •  Allgemeine Betriebswirtschaftslehre •  Apache •  Basiswissen für Selbstständige •  Bewerbungstipps •  Calc Basis •  Dreamweaver CS4 •  eBusiness •  eCommerce •  eGovernment •  Erinnerung an Douaumont •  Excel 2002 •  Excel 2003 Basis •  Excel 2003 Prof •  Excel 2007 Basis •  Excel 2007 Prof. •  Excel 2010 Basis •  Finanzmanagement •  HTML •  HTML CSS •  HTML Grundlagen •  Industriegütervertrieb •  Internet Technik •  JAVA •  JavaScript •  Lernen ohne Lehrer •  Marketing •  Markup-Sprachen •  Organisation und Technologiemanagement •  osCommerce •  Outlook 2003 •  Outlook 2007 •  Perl und CGI •  Personalmanagement •  PHP 4.3 •  PowerPoint 2003 •  Powerpoint 2007 •  Powerpoint 2010 •  Projektmanagement und MS Project 2000 •  Projektplanung und Projektoptimierung mit MS Project 2003 •  Rechnungswesen mit Beispielen •  Sicher auftreten •  SQL •  TEIA-Internet-Führerschein •  Unternehmensführung •  US-GAAP und IAS/IFRS •  Vertragswesen eBusiness •  Vista •  VWL •  Warum ich kein Christ sein will •  Widerstand •  Windows XP •  Wirtschaftsrecht •  Word 2002 •  Word 2003 Basis •  Word 2003 Prof. •  Word 2007 Basis •  Word 2007 Prof. •  Writer Basis •  XML •  XML Grundlagen •  XML XSL

Letzte Aktualisierung: 29.07.2010 13:03:17

Letzte Inhaltliche Überarbeitung: 29.06.2009 15:55:20

© 2000 - 2010 TEIA AG - Internet Akademie und Lehrbuch Verlag