HTTP:

Das Hyper Text Tranfer Protocol (V1.1 - RFC2616) basiert ebenfalls auf TCP/IP und ist somit auch Verbindungsorientiert. Das HTTP ist das zugrundeliegende Protokoll für das WWW in der Application Layer. HTTP übermittelt Daten vom Webserver zum Webbrowser und umgekehrt. Übertragen werden HTML-Dokumente (HyperText Markup Language) sowie einige Erweiterungen wie Bilddateien, Audiodateien etc. Die Spezialisierung der zusätzlichen Formate finden auf Browser und Server über die s.g. MIME.Types statt. Zwischen Browser (Client) und Server wird über das TCP/IP eine Verbindung hergestellt und über die URL (Unified Ressource Locators - Format für Pfadangaben im Internet) wird eine bestimmte Datei aufgerufen. Diese Datei besteht meistens aus HTML-Code und anderen implementierten Datenformaten wie z.B. .jpg, .png oder .gif als typische Bildformate im Internet.

Sind die Daten an den Browser übermittelt, wird die Verbindung zum Server wieder beendet. Um Daten vom Server anzufordern wird zuerst die Initial Request Line gesendet. Diese besteht aus dem Aufruf einer bestimmten Methode. Die Methode zum Anfordern heißt GET. Anschließend folgt die Pfadangabe auf dem Server für das gesuchte File, dann die benutzte HTTP-Version.

GET /path/to/file/index.shtml HTTP/1.0

Um größere Datenmengen zu übergeben wird die POST-Methode verwendet. Hier werden Daten nicht über die URL sondern im Kontext der Anfrage übertragen.

Mit der PUT-Methode können Daten unter der angegebenen URL abgelegt werden, wenn dieses der Server zulässt.

Der angesprochene Server sendet dann die so genannte Initial Response Line (Status Line) die ebenfalls aus drei Teilen besteht. Zuerst die HTTP Version, dann der response status und die zugehörige Kurzbeschreibung.

http/1.9 404 Not found

Der Response Status Code besteht aus einer dreistelligen Zahl. Aufgrund der ersten Ziffer kann er in folgende Gruppen eingeteilt werden:

• 1xx - zur Information
• 2xx - Erfolgsmeldung
• 3xx - Client wird umgeleitet auf eine andere URL
• 4xx - Fehler clientseitig
• 5xx - Fehler serverseitig

Beispiele sind:

• 200 OK: Erfolgreiche Anfrage
• 404 Not found: das angeforderte File konnte nicht gefunden werden
• 301 Moved permanently: Umleitung
• 302 Move temporarely: vorübergehende Umleitung
• 400 Bad request: Anfrage enthält falsche Syntax
• 500 Server Error: Fehler beim Aufrufen der Datei auf dem Server

Der angesprochene Server sendet dann die so genannte Initial Response Line (Status Line) die ebenfalls aus drei Teilen besteht. Zuerst die HTTP Version, dann der response status und die zugehörige Kurzbeschreibung.

http/1.9 404 Not found

Der Response Status Code besteht aus einer dreistelligen Zahl. Aufgrund der ersten Ziffer kann er in folgende Gruppen eingeteilt werden:

• 1xx - zur Information
• 2xx - Erfolgsmeldung
• 3xx - Client wird umgeleitet auf eine andere URL
• 4xx - Fehler clientseitig
• 5xx - Fehler serverseitig

Beispiele sind:

• 200 OK: Erfolgreiche Anfrage
• 404 Not found: das angeforderte File konnte nicht gefunden werden
• 301 Moved permanently: Umleitung
• 302 Move temporarely: vorübergehende Umleitung
• 400 Bad request: Anfrage enthält falsche Syntax
• 500 Server Error: Fehler beim Aufrufen der Datei auf dem Server

Danach können mehrere Headerlines folgen, in denen weitere Informationen vom Client oder Server abgelegt werden. HTTP 1.0 kennt 16 verschiedene Headerlines, diese sind für eine reguläre Verbindung nicht erforderlich.

Beispiele:

Client:

• Accept: MIME-Type des Browsers
• From: gibt die E-Mail Adresse des Benutzers an
• User-Agent: gibt das Programm an, dass diese Anfrage macht (User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0))

Server:

• Server: gibt die Serversoftware an (Server: Apache/1.3.20 (Linux/SuSE) mod_ssl/2.8.4 OpenSSL/0.9.6b PHP/4.0.6 FrontPage/4.0.4.3)
• Last Modified: das Datum der letzten Änderung (Mon, 07 Oct 2002 07:50:34 GMT)
• Content-Length: Länge des BODY Inhalts
• Content-Type: MIME-Type des BODY

Abschließend folgt eine Leerzeile und danach der BODY mit den Daten für den User.

Vom Client aus können ebenfalls Daten, die vom User eingegeben wurden, übertragen werden. Über eine Angabe im Feld Content-Type des Headers wird der MIME-Type des BODYs übertragen (Content-Type: text/html für ein HTML Dokument) und über Content-Length die Größe der Datei.

Verwendet man statt GET die HEAD-Methode, so werden nur die Header-Daten ausgetauscht. Mit der POST-Methode werden Daten an ein Script auf dem Server geschickt. Als Pfad ist dann das entsprechende Script anzugeben, die Antwort ist das Auswertungsergebnis dieses Scripts (CGI, Perl etc.)

Die Version 1.1 des HTTP wird seit etwa 1997 verwendet und ist zur Version 1.0 abwärtskompatibel. V1.1 ist durch eine Datenkompression und kleinere Pakete bis zu 10mal schneller als V1.0. Sie unterstützt die CSS und das Bildformat PNG. Weitere Vorteile sind u.a. die Möglichkeit mehrere Aktionen über eine bestehende Verbindung durchzuführen. Ein zusätzlicher Cache-Support. Bei dynamischen Seiten besteht die Möglichkeit diese zu versenden ohne die Gesamtgröße zu kennen (Chunked-Transfer-Encoding).

Im Gegensatz zur V1.0 werden aber bestimmte Header-Felder benötigt. Clientseitig und Serverseitig ist die Angabe des Zielhosts (Host) erforderlich, da man mehrere Hosts einer IP-Adresse zuordnen kann (multi-homed Server). Die Aufforderung die Verbindung nach dem Transfer zu schließen (Connection: close) muss ebenfalls explizit angegeben werden, da hier die Verbindung sonst bis zu einem Timeout von Seiten des Servers offen bleibt.

Protokollversionen

Derzeit werden zwei Protokollversionen, HTTP/1.0 und HTTP/1.1 verwendet.

Bei HTTP/1.0 wird vor jeder Anfrage eine neue TCP-Verbindung aufgebaut und nach Übertragung der Antwort wieder geschlossen. Sind in ein HTML-Dokument beispielsweise zehn Bilder eingebettet, so werden insgesamt elf TCP-Verbindungen benötigt, um die Seite auf einem grafikfähigen Browser aufzubauen. In der Version 1.1 können mehrere Anfragen und Antworten pro TCP-Verbindung gesendet werden. Für das HTML-Dokument mit zehn Bildern wird so nur eine TCP-Verbindung benötigt. Da die Geschwindigkeit von TCP-Verbindungen zu Beginn auf Grund des Slow-Start-Algorithmus recht gering ist, wird so die Ladezeit für die gesamte Seite signifikant verkürzt. Zusätzlich können bei HTTP/1.1 abgebrochene Übertragungen fortgesetzt werden. Informationen aus früheren Anforderungen gehen verloren (zustandsloses Protokoll). Über Cookies in den Header-Informationen können aber Anwendungen realisiert werden, die Statusinformationen (Benutzereinträge, Warenkörbe) zuordnen können. Dadurch können Anwendungen, die Status- bzw. Sitzungseigenschaften erfordern, realisiert werden. Auch eine Benutzerauthentifizierung ist möglich. Normalerweise kann die Information, die über HTTP übertragen wird, auf allen Rechnern und Routern, die im Netzwerk durchlaufen werden, gelesen werden. Über HTTPS kann die Übertragung verschlüsselt erfolgen.

Die Kommunikation der beteiligten Rechner kann mit Werkzeugen zur Netzwerkanalyse (zum Beispiel Ethereal) anschaulich nachvollzogen werden.

Eine Möglichkeit zum Einsatz von HTTP/1.1 in Chats ist die Verwendung des MIME-Typs multipart/replace, bei dem der Browser nach Sendung eines Boundary-Codes und einem neuerlichen Content-Length-Headerfeld sowie eines neuen Content-Type-Headerfeldes den Inhalt des Browserfensters komplett erneuert.

Mit HTTP/1.1 ist es neben dem Abholen von Daten auch möglich, Daten zum Server zu übertragen. Mithilfe der PUT-Methode können so Webdesigner ihre Seiten direkt über den Webserver per WebDAV publizieren, und mit der DELETE-Methode ist es ihnen möglich, Daten vom Server zu löschen.

Außerdem bietet HTTP/1.1 eine TRACE-Methode, mit der man den Weg zum Webserver verfolgen kann und überprüfen kann, ob die Daten korrekt dorthin übertragen werden. Mithilfe dieser Methode ergibt sich die Möglichkeit, den Weg zum Webserver über die verschiedenen Proxies hinweg zu ermitteln, ein traceroute auf Anwendungsebene.

HTTP-Request-Methoden

• GET ist die gebräuchlichste Methode. Mit ihr werden Inhalte vom Server angefordert.
• POST ähnelt der GET-Methode, nur dass ein zusätzlicher Datenblock übermittelt wird. Dieser besteht üblicherweise aus Name/Wert-Paaren, die aus einem HTML-Formular stammen. Grundsätzlich können Daten auch mittels GET übertragen werden (als Argumente im URI), aber die zulässige Datenmenge ist bei POST deutlich größer.
• HEAD weist den Server an, die gleichen HTTP-Header wie ein GET oder POST, nicht jedoch den eigentlichen Dokumentinhalt selbst zu senden. So kann z. B. schnell die Gültigkeit einer Datei im Browsercache geprüft werden.
• PUT dient dazu, Dateien unter Angabe des Ziel-URIs auf einen Webserver hochzuladen. Dies ist jedoch kaum implementiert.
• DELETE löscht die angegebene Datei auf dem Server. Dies ist jedoch kaum implementiert.
• TRACE liefert die Anfrage so zurück, wie der Server sie empfangen hat. So kann überprüft werden, ob und wie die Anfrage auf dem Weg zum Server verändert worden ist – sinnvoll für das Debugging von Verbindungen.
• OPTIONS liefert eine Liste der vom Server unterstützen Methoden und Features.
• CONNECT wird von Proxy-Servern implementiert, die in der Lage sind, SSL-Tunnel zur Verfügung zu stellen.

HTTP-Statuscodes

• 1xx: Informationen
  • 100: Continue
    • ab HTTP/1.1
    • Verwendet im Zusammenhang mit dem "Expect: 100-continue" Header
    • Die laufende Anfrage an den Server wurde noch nicht zurückgewiesen. Der Client kann also mit der (potentiell sehr großen) Anfrage fortfahren
  • 101: Switching Protocols
• 2xx: Erfolgreiche Operation
  • 200: OK
  • 201: Created
  • 202: Accepted
  • 203: Non-Authoritative Information
  • 204: No Content
  • 205: Reset Content
  • 206: Partial Content
    • ab HTTP/1.1
    • Verwendet im Zusammenhang mit einem "Content-Range" Header oder einem Content-Type von multipart/byteranges
    • Der angeforderte Teil wurde erfolgreich übertragen
• 3xx: Umleitung
  • 300: Multiple Choices
  • 301: Moved Permanently
  • 302: Found
  • 303: See Other
  • 304: Not Modified
  • 305: Use Proxy
  • 307: Temporary Redirect
• 4xx: Client-Fehler
  • 400: Bad Request
  • 401: Unauthorized
  • 402: Payment Required (in HTTP/1.1 noch nicht spezifiziert)
  • 403: Forbidden
  • 404: Not Found
    • Die angeforderte Ressource wurde nicht gefunden.
  • 405: Method Not Allowed
  • 406: Not Acceptable
  • 407: Proxy Authentication Required
  • 408: Request Time-out
  • 409: Conflict
  • 410: Gone
    • ab HTTP/1.1
    • Ungebräuchlich
    • Die angeforderte Ressource wird nicht länger bereitgestellt. Eine neue Adresse der Ressource ist nicht bekannt
  • 411: Length Required
  • 412: Precondition Failed
  • 413: Request Entity Too Large
  • 414: Request-URI Too Large
  • 415: Unsupported Media Type
  • 416: Requested range not satisfiable
  • 417: Expectation Failed
    • ab HTTP/1.1
    • Verwendet im Zusammenhang mit einem "Expect" Header
    • Das im "Expect" Header geforderte Verhalten des Servers kann nicht erfüllt werden
• 5xx: Server-Fehler
  • 500: Internal Server Error
  • 501: Not Implemented
  • 502: Bad Gateway
  • 503: Service Unavailable
  • 504: Gateway Time-out
  • 505: HTTP Version not supported