<jsptutorial />

Anhang I: HTTP-Grundlagen


HTTP - Ein zustandloses Protokoll

Das ganze Tutorial handelt davon, wie mittels Java-basierter Technologien ein Inhalt auf einem Server erzeugt wird, der von einem Client (zumeist einem Webbrowser wie bspw. Mozilla Firefox) abgerufen und verarbeitet (also bspw. angezeigt) wird.
HTTP, das HyperText Transfer Protocol, definiert dabei, wie die Kommunikation zwischen Client und Server aussieht, welche Nachrichten vom Client zum Server gesendet werden und auf welche Weise der Server darauf reagiert. Derartige Kommunikationsrichtlinien werden Protokolle genannt. Klar ist: Ein Grundverständnis von HTTP ist unverzichtbar für die Arbeit mit JSPs, bzw. mit Web-Anwendungen ganz allgemein.
Schauen wir uns kurz einen typischen Ablauf der Kommunikation zwsichen Client und Server an (im Folgenden schreiben wir vereinfachend immer vom Browser, aber andere Clients, wie bspw. Web-Service-Clients, die HTTP als Kommunikationsprotokoll nutzen, funktionieren genauso):

  1. Der Client muss zunächst einmal den Namen des Servers in eine IP-Adresse übermitteln. Dazu dienen DNS-Server (Domain Name System), die - etwas vereinfacht gesagt - auf Anfragen zu einem Namen eine IP-Adresse liefern.

  2. Danach fordert der Browser vom zugrunde liegenden Betriebssystem eine Verbindung zu dem Zielport (i.a.R. ist dies der Port 801) an. Dabei greift sich das Betriebssystem einen freien Port auf dem Client-Rechner und versucht die Verbindung aufzubauen. Dabei kommt als zugrundeliegendes Protokoll TCP (Transmission Control Protocol) zum Einsatz.

  3. Ist die Verbindung zustande gekommen, wird die HTTP-Anfrage (im Folgenden und im Rahmen dieses Tutorials immer Request genannt) vom Browser über diese Verbindung zum Server gesendet.

  4. Der Server seinerseits lauscht permanent auf Anfragen auf dem Zielport. Kommt eine Anfrage herein, so wird ein neuer Prozess oder Thread genutzt, um diese Anfrage zu bearbeiten. Der Server lauscht anschließend sofort wieder auf weitere Anfragen. Dadurch können mehrere Anfragen gleichzeitig beantwortet werden.

  5. Jede Anfrage wird mit einer Response beantwortet. Diese kann im Zweifelsfall lediglich aus einer Statusmeldung bestehen (bspw. der berühmten Meldung, dass eine Seite auf dem Webserver gar nicht vorhanden ist). Oder aber sie kann den Inhalt enthalten, den der Client angefordert hat. Dies kann bspw. eine Grafik sein, oder eine HTML-Seite. Mittels JSPs wird zumeist HTML erzeugt, der an den Client zurückgegeben wird. Grafiken und anderer nicht-textueller Inhalt wird hingegen zumeist mittels Servlets erzeugt oder statisch direkt aus dem Dateisystem geholt.

  6. Ist die Response vom Server zurück geschickt worden, wird abschließend die Verbindung zwischen Client und Server wieder geschlossen. Ein Umstand, der noch genauer betrachtet werden muss.

HTTP ist für die Entwicklerin ein gnädiges Protokoll. Es ist ausschliesslich Text-basiert, so dass es leicht gelesen werden kann und die Anzahl der HTTP-Methoden, der "Kommandos" ist begrenzt. Praktisch sind im Wesentlichen sogar nur drei von Bedeutung: GET, POST, HEAD und evtl. mit weitem Abstand noch TRACE. Mittels des Telnet-Tools kann man sogar leicht selber testweise einen Request absenden, wie das folgende Beispiel zeigt.

[centipede]$ telnet www.jsptutorial.org 80
Trying 217.160.172.47...
Connected to www.jsptutorial.org (217.160.172.47).
Escape character is '^]'.
GET /examples/code_first_simple_hello_world.jsp HTTP/1.1
Host: www.jsptutorial.org
User-Agent: telnet_test_browser

HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=630B96C76FA96C0EB63E17B3D8A3A759; Path=/
Content-Type: text/html
Content-Length: 176
Date: Mon, 15 Nov 2004 21:33:09 GMT
Server: Apache-Coyote/1.1

<html>
<head><title>First Example</title></head>
<body>
<h3>Hello World-JSP</h3>

Your browser is: telnet_test_browser<br>
Your IP address is: 192.168.0.20<br>

</body>
</html>

Hier wird in der ersten Zeile mittels "telnet" eine Verbindung zum Server "www.jsptutorial.org" auf Port 80 angefordert. Mit "Connected to 217.160.172.47" wird vom Telnet-Tool gemeldet, dass die Verbindung steht. Auch die nächste Zeile kommt vom Telnet-Programm. Danach wartet ein Cursor-Prompt auf eine Eingabe. Allzu viel Zeit darf man sich hier nicht lassen, da sonst die Verbindung nach einem voreingestellten Timeout-Wert schon wieder unterbrochen wird. Dies ist auch notwendig, würde doch sonst der Server schnell durch nicht geschlossene Verbindungen lahm gelegt werden.
Nun kommt der interessante Teil. Die von uns eingegebene Zeile "GET /examples/first_simple_hello_world.jsp HTTP/1.1" gibt an, welche Methode verwandt werden soll (GET), welche Ressource angefordert wird ("/examples/first_simple_hello_world.jsp") und welche HTTP-Protokoll-Version verwandt wird (hier HTTP 1.1). Danach folgen zwei Header-Zeilen. Beide werden praktisch von jedem Browser mitgesandt. Der User-Agent identifiziert z.B. den verwendeten Browser. Mit einer leeren Zeile teilen wir dem Server mit, dass der Header-Bereich abgeschlossen ist. In unserem Beispiel endet damit auch die Anfrage. Bei POST-Requests würden nach der Leerzeile noch die Nutzdaten übertragen.
Der Server antwortet nun mit den Response-Headern. Als erstes erfolgt die Bestätigung der HTTP-Methode. Würde HTTP 1.1 (die derzeit aktuelle Version) nicht unterstützt, würde hier bspw. "HTTP/1.0" stehen. Danach kommt der Status-Code und eine kurze Angabe zum Code. In unserem Fall der Code 200, der einen Erfolg anzeigt. Es folgen diverse Angaben, wovon besonders die Angabe zur Länge des Contents wichtig ist. Anhand dieser weiß der Browser auch dann noch, wann der Response vollständig ist, wenn Keep-Alive2 eingeschaltet ist.
Nach einer die Response-Header abschließenden Leerzeile kommt schlussendlich die eigentlich angeforderte HTML-Seite. Danach bricht Telnet ab, da die Verbindung vom Server getrennt wurde.
Die Leerzeilen am Ende der Request- und Response-Header sind verpflichtende Elemente der HTTP-Spezifikation. Damit wird angezeigt, dass anschließend keine weiteren Header mehr folgen, sondern der eigentliche Content gesendet wird. Mithilfe unseres VisualProxy-Tools werden wir im weiteren Verlauf dieses Kapitels noch mehr Beispiele für die Funktionsweise von HTTP geben.
Erwähnenswert ist vielleicht noch, dass HTTP bereits Ende der Achtziger am CERN, dem Schweizer Kernforschungsinstitut, von Tim Berners-Lee entwickelt wurde. Um so beachtenswerter, dass die derzeitige Version gerade mal die Versionsnummer 1.1 trägt. Wie bei den meisten Internet-Protokollen erwies sich auch bei HTTP die Stärke in der Beschränkung auf das Wesentliche und in einer vergleichsweisen einfachen Struktur.

Was bedeutet nun zustandslos?


Wie wir schon oben geschrieben haben, wird jede TCP-Verbindung nach der Antwort des Servers wieder abgebaut3.
Dies bedeutet zunächst einmal, dass für jede nachfolgende Anfrage wieder eine neue Verbindung aufgebaut werden muss. Es ist somit nicht möglich, seitens des Servers bestimmte Attribute der Verbindung zuzuordnen. Denn die nächste Anfrage kann selbst dann, wenn sie von der gleichen IP-Adresse kommt, von einem anderen Client gestellt sein. Eine eindeutige Zuordnung von einzelnen Anfragen zu bestimmten Clients ist somit aufgrund des permanenten Verbindungsabbruchs nicht möglich. HTTP ist somit von seiner Natur her ein zustandloses Protokoll. Alle Informationen über den Client sind direkt nach Absenden der Antwort für den Server verloren.
Dies ist natürlich nicht wünschenswert. Wenn man auf einer Shopping-Seite ist, möchte man als Nutzerin schließlich nicht nach jedem Artikel direkt bestellen, sondern diesen zunächst erst in einen Shopping-Cart legen, evtl. wieder heraus nehmen, mit anderen Produkten vergleichen, usw. Wünschenswert ist, dass der gesamte Seitenaufenthalt als eine geschlossene Sitzung behandelt wird. Im Englischen und Web-Deutsch wird eine solche Sitzung Session genannt.
Natürlich könnten stets auch alle Informationen mit jeder Anfrage und jeder Antwort übertragen werden. Aber dies wäre eine unnötige Belastung für den Netzwerk-Verkehr und für uns Webentwickler extrem unangenehm. Aus diesem Grund wurden von Netscape die Cookies eingeführt. Dies sind kleine Text-Informationen, die in den Request- und Response-Headern mitgesendet werden. Im obigen Beispiel wurde bspw. vom Server versucht, ein Cookie namens "JSESSIONID" zu setzen. Dies ist das Standard-Cookie, das von der Servlet-Engine Tomcat genutzt wird. Wie man sieht, ist das Cookie selbst wenig aussagekräftig. Es dient lediglich dazu, einen eindeutigen Identifizierungs-Token für die Benutzerin zu generieren. Der Browser sendet anschließend mit jeder Anfrage dieses Cookie an den Server, womit dieser weiß, dass es sich um eine Nutzerin handelt, für die zuvor schon Daten gespeichert wurden (s. dazu auch das Kapitel "Session-Handling, Cookies und URL-Rewriting"). Ein Cookie wird im übrigen immer nur an den Server gesendet, von dem dieses Cookie ursprünglich gesetzt wurde. Also ein Cookie von amazon könnten wir vom Tutorial nicht auslesen - und umgekehrt.
Wird nun inmitten einer Session das Cookie von der Nutzerin im Browser gelöscht, so ist der Sitzungs-Zusammenhang unwiederbringlich verloren. Ist eine Nutzerin registriert, so sind wichtige Daten evtl. in einer Datenbank abgelegt und sind damit nach einem erneuten Login wieder vorhanden (so arbeitet bspw. amazons Warenkorb für bekannte Nutzerinnen). Hat man sich aber nicht anderweitig identifiziert - oder sind die Daten nicht in einer Datenbank gespeichert - so ist mit dem Löschen des Cookies die Information nicht mehr erreichbar. Das ist ein Problem, das man beim Entwickeln einer Anwendung unbedingt im Auge behalten sollte. Dazu mehr im Kapitel zum Session-Handling, Cookies und URL-Rewriting.
Um an dieser Stelle einem weit verbreiteten Vorurteil entgegenzutreten: Cookies an sich sind harmlos und keine Sicherheitsbedrohung. Sie sind allenfalls problematisch, wenn bestimmte Server über viele unterschiedlichen Seiten - bspw. über Banner oder unsichtbare Bilder - angesprochen werden. In dem Fall könnten auf dem Server Nutzungsprofile angelegt werden. Mit Mozilla und Firefox kann man daher bspw. bestimmte Seiten vom Setzen von Cookies generell ausschließen, aber Cookies für andere Seiten zulassen.
Neben Cookies gibt es mit dem URL-Rewriting im Übrigen noch eine andere Methode, den Zustand einer Sitzung von Seitenaufruf zu Seitenaufruf weiterzugeben. Dazu wird an die URL ein String angefügt, der wie beim Cookie eindeutig für einen Nutzer ist. Wie man Cookies und URL-Rewriting zum Session-Handling mit JSPs und Servlets nutzt, wird im Kapitel Session-Handling, Cookies und URL-Rewriting ausführlich behandelt.
Neben dem Problem der Sitzungsverwaltung bedeutet das permanente Schließen der Verbindungen außerdem einen etwas unschönen Overhead, da so für jede Anfrage zunächst eine TCP-Verbindung aufgebaut werden und am Ende der Antwort wieder abgebaut werden muss. Da sich heute nahezu jede Seite aus vielen Elementen, v.a. Bildern, aber auch ausgelagerten Stylesheet-und JavaScript-Dateien oder anderen multimedialen Elementen, zusammensetzt, ist dieser Overhead besonders unschön. Der Keep-Alive-Header (s. die Fußnote im vorigen Abschnitt) verhindert immerhin diesen Overhead, aber ändert nichts an der Zustandlosigkeit der HTTP-Verbindung, allein schon, weil er ein optionaler Header ist, an den sich weder Client noch Server gebunden fühlen müssen.

Zum SeitenanfangZum Seitenanfang

Aufbau der URLs

Mit HTTP ruft ein Client immer eine Ressource auf einem Server ab. Dies sind vor allem HTML-Dateien und multimediale Daten wie bspw. Bilder. Dabei wird die Adresse der Ressource über eine URL angegeben. Eine typische URL sieht dabei wie folgt aus:

http://www.jsptutorial.org/showTutorial.html?topic=lifecycle&lang=de

Der Aufbau ist immer "protocol://server:port/pathToResource?parameter". Im Beispiel oben wurde mit "http" angegeben, dass als Protokoll "HTTP" verwendet werden soll. Dies ist natürlich der Regelfall. Desweiteren kommen häufig noch "https" für eine gesicherte HTTP-Übertragung oder "ftp" für FTP-Übertragungen zum Einsatz. Danach folgt der DNS-Name des Servers oder seine IP-Adresse und ggf. davon per Doppelpunkt abgetrennt der Port, auf den zugegriffen werden soll. Der Port entfällt, wenn der Standardport des jeweiligen Protokolls verwendet wird. Für HTTP ist dies der Port 80, für HTTPS der Port 443. Danach nun folgt die Angabe des Pfades der Ressource, auf die zugegriffen werden soll. Dies ist hier die Ressource "showTutorial.html", also vermeintlich eine HTML-Datei. Diese liegt natürlich nicht direkt im Wurzelverzeichnis des Rechners, sondern unterhalb eines Wurzelverzeichnisses für die Webanwendung, der "Document Root". Im angegebenen Beispiel handelt es sich sogar um ein Servlet, das alle Anfrage mit der Extension ".html" bedient. Hinter dem Fragezeichen kommen noch zwei Parameter, die Hilfen für die Bearbeitung geben. Der erste Parameter "topic" gibt an, welches Kapitel angezeigt werden soll. Weitere Parameter müssen durch ein "&"-Zeichen abgetrennt werden. Hier wird als zweiter Parameter die Sprache übergeben.

Zum SeitenanfangZum Seitenanfang

VisualProxy - HTTP-Traffic ansehen

Da wir ein gutes Verständnis von HTTP als wichtig ansehen und da zudem ein solches Tool mitunter in der Praxis zum Debuggen und Verstehen von Abläufen wichtig sein kann, haben wir VisualProxy geschrieben, ein Programm mit dem man sich die HTTP-Requests und -Responses ansehen kann. Dieses Tool ist - wie die Engine hinter dem Tutorial - Freie Software und unterliegt der GNU - General Public License (GPL). Das Tool kann heruntergeladen werden unter http://www.visualproxy.org.
Derzeit ist das Tool noch in einem frühen Entwicklungsstadium, aber es reicht bereits aus, um fast alle Fälle abzudecken, und wird daher auch zur Demonstration in den folgenden beiden Abschnitten eingesetzt.

Zum SeitenanfangZum Seitenanfang

HTTP-Methoden

HTTP unterstützt in der Version 1.1 folgende sechs Methoden: GET, POST, HEAD, TRACE, PUT, DELETE, OPTIONS, CONNECT. Davon sind für uns im Rahmen dieses Tutorials eigentlich lediglich die Methoden GET, POST und HEAD interessant, die wir etwas ausführlicher beschreiben wollen. Die anderen werden danach nur kurz angerissen - viele Server unterstützen diese ohnehin nicht. Verpflichtend sind gemäß HTTP 1.1-Spezifikation sogar nur die beiden Methoden GET und HEAD, praktisch wird man aber wohl keinen Server finden, der nicht auch mindestens POST unterstützt.

GET

Die HTTP-Methode "GET" ist die meistgenutzte Methode. Wenn man eine URL in den Browser eintippt und den Request absendet, so ist dies immer ein GET-Request. Auch Formulare werden standardmäßig per GET abgesendet. Will man POST verwenden, so muss dies im HTML-Code explizit angegeben werden. GET dient dazu, eine Ressource an den Client auszuliefern. Einzelne Parameter können übermittelt werden, um die Erstellung oder Ermittlung der Ressource zu ermöglichen. Die Parameter werden dabei einfach durch ein Fragezeichen an die URL angehängt, wobei im Unterschied zu POST die Anzahl der Zeichen für Parameter - Browser- und/oder Server-abhängig - begrenzt ist. An GET ist soweit wenig Geheimnisvolles. Um den Unterschied zu POST nachher deutlicher zu machen, liefern wir hier zunächst einen Screenshot für einen GET-Request.
http_simple_get_request.png

POST

Mittels "POST"-Requests sollen umfangreiche Informationen an den Server übertragen werden können. Dies können Meldungen sein, aber auch Dateien. Ein File-Upload lässt sich mittels HTTP sogar ausschließich per POST-Requests vornehmen. Praktisch werden im Rahmen von Webanwendungen POST-Request vor allem für umfangreichere Formulare verwendet. Im Unterschied zum GET-Request werden bei POST die Parameter nicht an den Pfad der Ressource angehängt, sondern im Body des Requests selbst mitgesendet. D.h. die Parameter folgen, nachdem der Header-Bereich mit einer Leerzeile abgetrennt wurde.
Am besten sieht man den Aufbau von POST-Request im folgenden Screenshot:
http_simple_post_request.png
Bei einem File-Upload muss man das <FORM>-Element in der HTML-Seite wie folgt angeben:

<form action="uploadFile.do" enctype="multipart/form-data" method="POST">

Ein Request sieht dann wie im folgenden Screenshot aus (wobei natürlich Teile abgeschnitten werden mussten).
http_post_file_upload.png

HEAD

Mitunter ist es sinnvoll, nicht die gesamte Ressource anzufordern, sondern nur anzufragen, wie groß diese wäre, oder wie alt diese ist. So können Caches und Proxies herausfinden, ob die Ressourcen in ihrem internen Speicher noch aktuell sind oder neu angefragt werden müssen. HEAD ermöglicht genau dies. Gemäß Spezifikation sollen die Header-Informationen der Server-Response identisch sein mit denen eines GET-Requests plus dem Header "Content-Length". Der optionale Header "Content-Length" enthält hier die Angabe über die Größe der angeforderten Ressource.
http_simple_head_request.png

OPTIONS

Options ermöglicht dem Web-Client herauszufinden, welche Kommunikationsmöglichkeiten zur Verfügung stehen. Zumeist werden alle Ressourcen einfach normal beantwortet, wie bei einer GET-Anfrage.
Eine Besonderheit ist, wenn man anstelle eines Pfades auf eine bestimmte Ressource den Asterisk "*" verwendet. Dann werden alle Möglichkeiten des Servers generell als Antwort zurück gegeben, wie das folgende Beispiel zeigt:

[centipede]$ telnet www.jsptutorial.org 80
Trying 217.160.172.47...
Connected to www.jsptutorial.org (217.160.172.47).
Escape character is '^]'.
OPTIONS * HTTP/1.1
Host: 192.168.0.20

HTTP/1.1 200 OK
Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS
Content-Length: 0
Date: Mon, 13 Dec 2004 20:01:50 GMT
Server: Apache-Coyote/1.1

Connection closed by foreign host.

DELETE

Wie der Name schon sagt, soll dieser Request eigentlich dazu führen, dass die entsprechende Ressource gelöscht wird. Dies unterstützt natürlich kein Server, sonst könnte ja jeder mal eben per Telnet oder etwas raffinierteren Tools ganze Websites löschen. De facto wird DELETE häufig wie ein GET-Request behandelt. Dies ist in keinster Weise HTTP-konform. HTTP-konform wäre vielmehr die Zurückgabe einer der beiden Status-Codes 405 oder 501. Dies wird aber leider nicht so gehandhabt.

PUT

Mit PUT sollte es eigentlich möglich sein, Ressourcen zum Server zu übertragen, die anschließend unter der verwendeten URL zugänglich sein sollten. Auch dies wird natürlich aus Sicherheitsgründen von Servern heutzutage nicht unterstützt.

TRACE

TRACE dient der Diagnose. Der eingegangene Request soll dabei zurück an den Client gesendet werden. Auch dies ist aus Sicherheitsgründen häufig unterbunden.

CONNECT

Reserviert für Proxies zum Tunneling von Verbindungen, für Webanwendungen also unerheblich.

Zum SeitenanfangZum Seitenanfang

Wichtige HTTP-Statuscodes

HTTP-Statuscodes hat garantiert jeder schon mal gesehen. Die berühmten "Page Not Found"-Nachricht ist eine Meldung zum Statuscode 404 oder der Internal Server Error (beim Internet Explorer standardmässig kaschiert) entspricht dem Statuscode 500. Das sind aber nicht die einzigen Codes, über die man in der Web-Entwicklung stolpert.
Wir stellen weiter unten ein paar Codes vor, die häufiger vorkommen. Die gesammte Palette der Codes kann in der HTTP-Spezifikation nachgelesen werden.
Die Statuscodes sind immer dreistellige Zahlen und von der Spezifikation in fünf Gruppen eingeteilt:

Gruppe Bedeutung wichtige Codes der Gruppe
1xx Informationen -
2xx Erfolgsmeldungen 200, 206
3xx Request-Umleitung 301, 302, 304
4xx Client-Fehler 400, 401, 403, 404, 405, 408
5xx Server-Fehler 500, 501, 504, 505


Nun stellen wir kurz die in der dritten Spalte aufgeführten Codes und deren Bedeutung vor.

200 - OK


Dies ist zusammen mit 304 die erfreulichste Nachricht, die man bekommen kann. Sie zeigt an, dass alles gut gegangen ist. Die Response enthält die angeforderte Ressource.

206 - Partial Content


Eine Ressource wurde zuvor nicht komplett übertragen und ein Browser fordert nun den Rest der Ressource an. Dies kommt z.B. häufig bei Bildern vor. Die Nutzerin hat bspw. während noch ein bild übertragen wird, schon wieder auf einen Link geklickt. Kommt sie nun zurück zu der Seite, von wo aus sie dem Link gefolgt ist, so kann der Browser versuchen, die unterbrochene Bild-Übertragung an der Stelle wieder fortzusetzen und so Bandbreite zu sparen. Der Statuscode 206 zeigt nun an, dass dieser Versuch geglückt ist.

301 - Moved Permanently


Dieser Statuscode weist darauf hin, dass sich eine URL dauerhaft geändert hat. Bspw. wird die Anfrage nach "www.altavista.de" so beantwortet. Es wird an den Browser ein Response-Header "Location: newURL" gesendet, der die neue Adresse enthält (s. Screenshot). Alle mir bekannten Browser lösen diese Adresse danach automatisch auf und laden die Ressource von der neuen Adresse nach.
statuscode_301.png

302 - Moved Temporarily


Im Kern vergleichbar mit 301. Nur, dass die URL sich hier nicht dauerhaft geändert hat. Manche Server senden diesen Code, wenn man nicht die Ressource, sondern nur einen Pfad angibt. Bspw. wird der Code beim Aufruf der Seite "http://www.jsptutorial.org" gesendet. Es gibt aber auch Server, die dafür keinen Redirect durchführen. Auch hier empfiehlt die HTTP-Spezifikation, einen Location-Header in der Response mitzusenden, so dass Browser automatisch die angegebene neue Adresse anfordern können.

304 - Not modified


Wenn der Browser einen Cache nutzt, so sendet er diverse Header bei seinem Request mit (s. Screenshot), anhand denen der Server erkennen kann, ob der Client eine aktuelle Ressource schon hat oder nicht. Hat der Client eine aktuelle Ressource, so wird der Code 304 gesendet und der Browser holt die Ressource zur Darstellung aus seinem Cache.
statuscode_304.png

400 - Bad Request


Dieser Code zeigt an, dass die Anfrage nicht gemäß der Spezifikation ist. Dies lässt sich mit Telnet einfach nachstellen, in dem man einen HTTP 1.1-Request absendet, aber den Header "Host" nicht mitsendet. In einem Browser wird man den Code wohl eher nie zu sehen bekommen.

401 - Unauthorized


Hier wurde der Nutzerin die Möglichkeit gegeben, sich zu authentifizieren, aber die Authentifizierung schlug fehl. Anstelle der angeforderten Ressource wird daher diese Fehlermeldung zrückgegeben.

403 - Forbidden


Diese Anfrage wird niemals erfüllt werden. Dies ist bspw. häufig der Fall, wenn man nur ein Verzeichnis angibt, der Inhalt des Verzeichnisses aber nicht preisgegeben werden soll.

404 - Not Found


Jeder kennt ihn. Unzählige Links im Internet führen ins Leere und man bekommt als Meldung genau diesen Statuscode und eine mal mehr, mal weniger schöne Seite, die einen mitteilt, dass unter der angegebenen URL keine Ressource existiert.

406 - Not Acceptable


Wenn man eine Ressource per GET anfordert, aber nur POST unterstützt wird, so gibt der Server diese Meldung zurück. Kommt eher selten vor, aber man kann es nutzen, wenn man unbedingt sicherstellen will, dass bestimmte Ressourcen nur mit definierten HTTP-Methoden angefordert werden dürfen.

408 - Request Timeout


Hier hat der Client seinen Request nicht innerhalb eines vom Server festgelegten Timeouts abgesendet. Bei Browsern tritt dieser Fehler garantiert nie auf, aber wenn man per Telnet einen Request von Hand aus eingibt, kann einem dieser Statuscode schon mal begegnen.

500 - Internal Server Error


Der übelste Fehler. In der Java-Welt bedeutet das nahezu immer, dass irgendwo eine Exception aufgetreten ist und diese nun für die Nutzerin sichtbar ist. Seinen Nutzerinnen sollte man diesen Fehler durch geeignete Fehlerseiten ersparen. Im Kapitel "Fehler- und Ausnahmenbehandlung" gehen wir ausführlich auf die Möglichkeiten ein, Fehler abzufangen oder doch zumindest für die Nutzerin akzeptabel gestaltete Hinweisseiten für unbehebbare Fehler zu erstellen.

501 - Not Implemented


Hier wurde eine HTTP-Methode verwendet, die der Server nicht unterstützt. Dies könnte bspw. PUT oder DELETE sein, oder eine falsch geschriebene Methode, die es laut Spezifikation nicht gibt. Auf nicht unterstützte Methode reagieren die Server auf nicht unterstützte Methoden (bspw. PUT oder DELETE) mit einer Auslieferung der Ressource. Den Fehler bekommt man daher i.a.R. nur, wenn man sich bei Telnet verschreibt.

504 - Gateway Timeout


Diese Meldung wird vom Gateway oder einem Proxy-Server generiert. Der von diesem kontaktierte eigentliche Webserver hat dann für die Antwort zu lange gebraucht.

505 - HTTP Version Not Supported


Dies dürfte v.a. bei älteren Servern der Fall sein. Nahezu alle modernen Browser nútzen standardmässig HTTP 1.1. Server, die nur HTTP 1.0 unterstützen antworten daher mit diesem Code. Server, die HTTP 1.1 unterstützen müssen auch HTTP 1.0-Anfragen unterstützen, daher wird man mit alten Browsern diesen Fehler nicht erhalten. I.a.R. dürfte der browser diesen Fehler vor einem verstecken, indem er einfach den Request nochmal als HTTP 1.0-Anfrage absendet.

Zum SeitenanfangZum Seitenanfang

Anmerkungen:

1) Wird ein anderer Port als der Standardport benutzt, so wird dieser an den Servernamen, durch einen Doppelpunkt abgetrennt, angefügt. (zurück)

2) Keep-Alive ist ein HTTP-Header, der in der Version 1.1 hinzugekommen ist, um zumindest das permanente Öffnen und Schließen von Verbindungen einzusparen. Mit ihm kann ein Zeitrahmen angegeben werden, innerhalb dessen die Verbindung für eventuelle Folgeanfragen offen gehalten werden sollte. Das im nächsten Abschnitt Gesagte zur Zustandslosigkeit wird dadurch aber nicht gegenstandlos. Jeder HTTP-Request gilt nach wie vor als eigenständig - selbst dann wenn er über eine offen gehaltene Verbindung vorgenommen wurde. (zurück)

3) Dies ist mit HTTP 1.1 nicht mehr ganz korrekt. Dort gibt es den "Keep-Alive"-Header; s. dazu die Fußnote im vorigen Abschnitt. (zurück)


www.jsptutorial.org
© 2005, 2006, 2007