Hypertext Transfer Protocol: Unterschied zwischen den Versionen
Michi (Diskussion | Beiträge) (Die Seite wurde neu angelegt: Das Netzwerkprotokoll <b>Hypertext Transfer Protocol / HTTP</b> wird vor allem eingesetzt, um Webseiten und andere Daten von einem Webserver aus dem [[World...) |
Michi (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
(7 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
Das [[Netzwerkprotokoll]] <b>Hypertext Transfer Protocol / HTTP</b> wird vor allem eingesetzt, um [[Webseite]]n und andere Daten von einem [[Webserver]] aus dem [[World Wide Web]] in einen [[Webbrowser]] zu laden. | Das [[Netzwerkprotokoll]] <b>Hypertext Transfer Protocol / HTTP</b> wird vor allem eingesetzt, um [[Webseite]]n und andere Daten von einem [[Webserver]] aus dem [[World Wide Web]] in einen [[Webbrowser]] zu laden. | ||
HTTP 1.0 wurde im Mai 1996 in der RFC 1945 veröffentlicht, im August 1996 folgte HTTP 1.1. Wie [[finger]], [[telnet]] und [[echo]] ist auch HTTP ein verbindungs- oder statusloses Protokoll. Server und Client nehmen also nie einen besonderen Zustand an, sondern beenden nach jedem Befehl den Prozess vollständig, entweder mit Erfolg oder mit einer Fehlermeldung. Es obliegt dem | HTTP 1.0 wurde im Mai 1996 in der RFC 1945 veröffentlicht, im August 1996 folgte HTTP 1.1. Wie [[finger]], [[telnet]] und [[echo]] ist auch HTTP ein verbindungs- oder statusloses Protokoll. Server und Client nehmen also nie einen besonderen Zustand an, sondern beenden nach jedem Befehl den Prozess vollständig, entweder mit Erfolg oder mit einer Fehlermeldung. Es obliegt dem Kommunikationspartner, darauf in angemessener Weise zu reagieren. | ||
Für Streaming eignet sich HTTP nicht | Für Streaming eignet sich HTTP nicht besonders, denn sobald durch Paketverluste Aussetzer entstehen, schaukelt sich der Effekt noch hoch, weil die verlorenen Pakete neu übertragen werden. | ||
== Protokollaufbau == | == Protokollaufbau == | ||
HTTP-Befehle können aus mehreren Zeilen bestehen. Die erste Zeile ist immer die Befehlszeile. Daran angehängt kann ein sogenannter Message-Header folgen. Dieser Header enthält weitere Parameter, die den Befehl näher bestimmen. So kann ein "Content-Length"-Feld enthalten sein. Steht dort ein Wert grösser als 0, so folgen dem Header Daten. Die Daten werden also gleich zusammen mit dem Befehl gesendet - man spricht dann vom "Body" der Nachricht. HTTP versteht im Gegensatz zu [[SMTP]] den Umgang mit 8-Bit-Werten. Binärdaten wie Bilder oder Klänge müssen nicht umgewandelt werden. Folgen dem HTTP-Befehl und den Header-Zeilen zwei Leerzeichen, (Zeilenwechsel "\n"), so gilt der Befehl als beendet. Befehle mit Body haben kein besonderes Endezeichen, das "Content-Length"-Feld bestimmt, wieviele | HTTP-Befehle können aus mehreren Zeilen bestehen. Die erste Zeile ist immer die Befehlszeile. Daran angehängt kann ein sogenannter Message-Header folgen. Dieser Header enthält weitere Parameter, die den Befehl näher bestimmen. So kann ein "Content-Length"-Feld enthalten sein. Steht dort ein Wert grösser als 0, so folgen dem Header Daten. Die Daten werden also gleich zusammen mit dem Befehl gesendet - man spricht dann vom "Body" der Nachricht. HTTP versteht im Gegensatz zu [[SMTP]] den Umgang mit 8-Bit-Werten. Binärdaten wie Bilder oder Klänge müssen nicht umgewandelt werden. Folgen dem HTTP-Befehl und den Header-Zeilen zwei Leerzeichen, (Zeilenwechsel "\n"), so gilt der Befehl als beendet. Befehle mit Body haben kein besonderes Endezeichen, das "Content-Length"-Feld bestimmt, wieviele Byte als Inhalt der Nachricht eingelesen werden. Ein HTTP-Befehl hat immer den folgenden Aufbau. Mit "Methode" oder "HTTP-Request-Methode" wird der Befehl selbst bezeichnet. | ||
<METHODE> ID VERSION | <METHODE> ID VERSION | ||
Zeile 99: | Zeile 99: | ||
An einen Befehl oder an die Statuszeile können weitere Felder angehängt werden. Der Aufbau lehnt sich an den [[MIME]]-Standard an. Die Header-Felder können in drei Hauptgruppen aufgeteilt werden. | An einen Befehl oder an die Statuszeile können weitere Felder angehängt werden. Der Aufbau lehnt sich an den [[MIME]]-Standard an. Die Header-Felder können in drei Hauptgruppen aufgeteilt werden. | ||
{| class=wikitable | {| class=wikitable width=100% | ||
! Gruppe !! Beschreibung | ! width=10% | Gruppe !! Beschreibung | ||
|- | |- | ||
| <tt>F</tt> || Fragefelder (Request-Header-Fields) sind nur in Befehlen erlaubt. | | <tt>F</tt> || Fragefelder (Request-Header-Fields) sind nur in Befehlen erlaubt. | ||
Zeile 283: | Zeile 283: | ||
== Weblinks == | == Weblinks == | ||
{{ | {{Weblinks}} | ||
{{url_dewikipedia|Hypertext_Transfer_Protocol|Hypertext Transfer Protocol}} | |||
{{Fuss}} | |||
Aktuelle Version vom 10. Februar 2013, 12:20 Uhr
Das Netzwerkprotokoll Hypertext Transfer Protocol / HTTP wird vor allem eingesetzt, um Webseiten und andere Daten von einem Webserver aus dem World Wide Web in einen Webbrowser zu laden.
HTTP 1.0 wurde im Mai 1996 in der RFC 1945 veröffentlicht, im August 1996 folgte HTTP 1.1. Wie finger, telnet und echo ist auch HTTP ein verbindungs- oder statusloses Protokoll. Server und Client nehmen also nie einen besonderen Zustand an, sondern beenden nach jedem Befehl den Prozess vollständig, entweder mit Erfolg oder mit einer Fehlermeldung. Es obliegt dem Kommunikationspartner, darauf in angemessener Weise zu reagieren.
Für Streaming eignet sich HTTP nicht besonders, denn sobald durch Paketverluste Aussetzer entstehen, schaukelt sich der Effekt noch hoch, weil die verlorenen Pakete neu übertragen werden.
Protokollaufbau
HTTP-Befehle können aus mehreren Zeilen bestehen. Die erste Zeile ist immer die Befehlszeile. Daran angehängt kann ein sogenannter Message-Header folgen. Dieser Header enthält weitere Parameter, die den Befehl näher bestimmen. So kann ein "Content-Length"-Feld enthalten sein. Steht dort ein Wert grösser als 0, so folgen dem Header Daten. Die Daten werden also gleich zusammen mit dem Befehl gesendet - man spricht dann vom "Body" der Nachricht. HTTP versteht im Gegensatz zu SMTP den Umgang mit 8-Bit-Werten. Binärdaten wie Bilder oder Klänge müssen nicht umgewandelt werden. Folgen dem HTTP-Befehl und den Header-Zeilen zwei Leerzeichen, (Zeilenwechsel "\n"), so gilt der Befehl als beendet. Befehle mit Body haben kein besonderes Endezeichen, das "Content-Length"-Feld bestimmt, wieviele Byte als Inhalt der Nachricht eingelesen werden. Ein HTTP-Befehl hat immer den folgenden Aufbau. Mit "Methode" oder "HTTP-Request-Methode" wird der Befehl selbst bezeichnet.
<METHODE> ID VERSION
Die folgende Tabelle zeigt alle HTTP-Befehle. Sie sind sämtlich in Grossbuchstaben zu schreiben.
Befehl | Beschreibung |
---|---|
DELETE | Ressource löschen |
GET | Ressource anfordern |
HEAD | Header der Ressource anfordern |
LINK | Verknüpfung zweier Ressourcen beantragen |
OPTIONS | Optionen des Webservers erfragen |
POST | Daten an einen Serverprozess senden |
PUT | Ressource auf dem Webserver ablegen |
TRACE | Befehl zurückschicken lassen |
UNLINK | Verknüpfung zwischen Ressourcen löschen |
Die ID einer Ressource kann beispielsweise eine Adresse oder ein Dateiname sein. Folgender Befehl fordert die datei "index.html" an.
GET index.htm HTTP/1.0
Statuscodes
Die Antwort auf einen Befehl besteht im Senden eines Statuscodes. Dem Statuscode folgen optionale Felder, und bei der Übertragung von Ressourcen die Daten. Die Statuszeile hat folgenden Aufbau. Der Statuscode ist eine dreistellige Ziffer, von denen die erste die Zuordnung zu einer bestimmten Gruppe zeigt.
VERSION STATUSCODE STATUSTEXT
Folgende Tabelle zeigt eine Übersicht über die wichtigsten Statusmeldungen.
Statuscode | Beschreibung |
---|---|
2xx: Befehl war erfolgreich | |
200 | Die Übertragung war erfolgreich und lief ohne Fehler ab. |
201 | Ein POST-Befehl wurde ausgegeben, es wurde erfolgreich eine Ressource erstellt und ereignislos ausgeführt. |
202 | Der Befehl des Clients wurde nach Authentifizierung vom Server für weitere Verarbeitung akzeptiert. |
203 | Der Server konnte die Anfrage des Clients nur teilweise ausführen. |
204 | Die Anfrage des Clients wurde bearbeitet, der Server konnte aber keine Daten zurückgeben, weil es keinen Inhalt gibt oder dieser nicht angefordert wurde. |
3xx: Weitere Reaktion erforderlich | |
300 | Der Client hat Daten verlangt, die vor kurzem an einen anderen Ort verschoben wurden. |
301 | Der Server hat die vom Client verlangten Daten (die Ressource) unter einer alternativen, temporär dortin umgeleiteten URL gefunden. |
302 | Ressource zur Zeit nicht verfügbar, der Server hat einen alternativen Standort für die vom Client angeforderten Daten vorgeschlagen. |
303 | Es gab ein Problem, weil der Server die verlangten Daten nicht modifizieren konnte. |
304 | Ressource wurde nicht verändert (steuert Proxy) |
4xx: Fehler, Wiederholung mit anderen Daten sinnvoll | |
400 | Der Client hat eine fehlerhafte Anfrage gestartet (Syntaxfehler). Diese konnte daher nicht bearbeitet werden. |
401 | Der Client hat versucht, auf Daten zuzugreifen, für die er keine Autorisierung hat. |
402 | Ein Zahlungsschema wurde gestartet. |
403 | Nicht öffentlicher Bereich, ein Zugriff ist nicht erlaubt. |
404 | Das Dokument wurde nicht gefunden. |
5xx: Serverfehler, Wiederholung zwecklos | |
500 | Interner Server-Fehler, von dem sich der Server nicht erholen kann (Fehlfunktion). Tritt häufig auf, wenn ein Client ein fehlerhaftes CGI-Skript aufruft. |
501 | Der Client hat eine Aktion verlangt, die der Server nicht durchführen kann oder nicht unterstützt. |
502 | Feldwert oder URL ungültig (nur Proxy); der Server ist überlastet. |
503 | Dienst nicht verfügbar. Der Server wartet darauf, dass ein anderer Gateway-Dienst Daten zurückgibt, aber der externe Dienst hängt oder ist ausgefallen. |
Der HTTP-Message-Header
An einen Befehl oder an die Statuszeile können weitere Felder angehängt werden. Der Aufbau lehnt sich an den MIME-Standard an. Die Header-Felder können in drei Hauptgruppen aufgeteilt werden.
Gruppe | Beschreibung |
---|---|
F | Fragefelder (Request-Header-Fields) sind nur in Befehlen erlaubt. |
A | Antwortfelder (Response-Header-Fields) kommen nur in der Antwort (Statusnachricht) vor. |
I | Informationsfelder (General-Header-Fields) übertragen alle anderen Nachrichten, wie Grössen und Parameter. |
Nicht alle Server stellen alle Felder zur Verfügung, teilweise ergeben sich durch die Weiterleitung der Nachrichten an den Nutzer erhebliche Sicherheitslücken - immerhin werden die Daten vom Webbrowser empfangen. Muss ein Feld mehrfach übertragen werden, so kann die Angabe der Werte als durch Kommas getrennte Liste oder durch Wiederholung der Feldnamen erfolgen.
Header-Field Wert, Wert, Wert ...
Alternativ können die Werte auch folgendermassen auftreten.
Header-Field Wert Header-Field Wert Header-Field Wert
Einige Header können untergeordente (optionale) Informationen enthalten. So kann dem Feld "Content-Type" der Name der Datei übergeben werden. Die Elemente werden dabei mit Strichpunkten getrennt.
Content-Type: application/pdf; name=bestellung.pdf
Die folgende Tabelle zeigt alle Header-Felder und die zugehörigen Gruppen.
Gruppe | Feldname | Beschreibung |
---|---|---|
F | Accept | MIME-Typen, die der Cleint verarbeiten kann. |
F | Accept-Charset | Bevorzugter Zeichensatz |
F | Accept-Encoding | Kodierung des Clients |
F | Accept-Language | |
I | Allow | Liste aller erlaubten Befehle |
F | Authorization | Authentifizierung der Clients |
I | Content-Disposition | Inhaltsbeschreibung einer MIME-Quelle |
I | Content-Encoding | Kodierung der Ressource |
I | Content-Language | Sprache der Ressource |
I | Content-Length | Grösse der Ressource (in Byte) |
I | Content-Type | MIME-Typ der Ressource |
I | Date | Absende- oder Erstellungsdatum |
I | Expires | Verfallsdatum der Ressource |
F | From | E-Mail-Adresse des Nutzers |
F | Host | Domainname des Webservers |
F | If-Modified-Since | Nur dann "GET", wenn neueren Datums |
I | Last-Modified | Aktualisierungsdatum der Ressource |
I | Link | Verknüpfung |
A | Location | URL der Ressource (bei Redirect) |
I | MIME-Version | MIME-Version des Headers |
I | Pragma | Allgemeiner Schalter "Name=Wert" |
F | Referer | URL der Herkunfts-Ressource |
A | Retry-After | Datum der nächsten Verfügbarkeit |
A | Server | Name und Version des Webservers |
I | Title | Titel der Ressource |
U | URI | URI der Ressource |
F | User-Agent | Name und Versionsnummer der Ressource |
A | WWW-Authenticate | Authentifizierungsschema |
Im Gegensatz zu anderen Protokollen wird die Länge eines Datenblocks mit dem Feld "Content-Length" festgelegt, irgendwelche Begrenzungszeichen gibt es nicht. Zu beachten ist auch, dass der Server nach dem Verbindungsaufbau keine Antwort sendet. Erst der erste eintreffende Befehl löst eine Reaktion aus. Darin ist die Ursache zu sehen, wenn die Webbrowser nach der Anforderung eines unerreichbaren Servers lange Zeit nicht reagieren. Als "Totsignal" wird einfach eine vorgegebene Zeit gewartet, in welcher der Server auf den ersten Befehl reagieren sollte.
Eine einfache HTTP-Verbindung könnte nun folgendermassen aussehen.
Client: (Verbindungsaufbau des Webbrowsers) Server: (keine Antwort) Client: GET /index.html HTTP/1.0 If-Modified-Since: Wed, 30 Jul 2007 00:00:00 <CR><LF> Server: HTTP/1.0 200 Document follows Date: Mon, 18 Aug 2007 23:22:10 GMT+200 Server: IIS 5.0, Microsoft Corporation Content-Type: text/html Last-Modified: Mon, 11 Aug 2007 14:39:13 Content-Length: 7245 <CR><LF> JDGGF/(&§=$(?ED... Daten ohne Endekennung
Wenn Header selbst ausgewertet werden, muss folgendes Datumsformat beachtet werden.
www, dd MMM YYYY HH:mm:ss GMT+xxx
Verwendung
Mit einem HTTP-Server kann über eine telnet-Sitzung an Port 80 direkt kommuniziert werden.
$ telnet www.linux-user.de 80 oder $ telnet www.linux-user.de http
Beispiel: Webseite ohne Webbrowser ansehen
Ansehen des Hauptdokuments von www.linux-user.de.
$ telnet www.linux-user.de 80 Trying 62.245.157.217... Connected to www.linux-user.de. Escape character is '^]'. GET / <html> ... </html> Connection closed by foreign host.
Ansehen des Hauptdokuments der Website "www.linux-user.de" mit zusätzlichen Header-Informationen, provoziert durch das Senden einer HTTP/1.0-Anfrage.
$ telnet www.linux-user.de 80 Trying 62.245.157.217... Connected to www.linux-user.de. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.1 200 OK Date: Wed, 20 Apr 2005 19:53:05 GMT Server: Zope/Zope 2.3.3 (binary release, python 1.5.2, linux2-x86) ZServer/1.1b1 Content-Type: text/html Content-Length: 35720 X-Cache: MISS from www.linux-user.de Connection: close <html> ... </html> Connection closed by foreign host.
Ansehen des Hauptdokuments von www.linux-user.de mit zusätzlichen Header-Informationen, provoziert durch das Senden einer HTTP/1.0-Anfrage.
$ telnet www.linux-user.de 80 Trying 62.245.157.217... Connected to www.linux-user.de. Escape character is '^]'. GET / HTTP/1.1 Host: meister.site HTTP/1.1 200 OK Date: Wed, 20 Apr 2005 19:59:44 GMT Server: Zope/Zope 2.3.3 (binary release, python 1.5.2, linux2-x86) ZServer/1.1b1 Content-Type: text/html Content-Length: 35727 X-Cache: MISS from www.linux-user.de <html> ... </html> Connection closed by foreign host.
Ansehen des Hauptdokuments von www.linux-user.de mit zusätzlichem Abspeichern in die Datei "file.html".
$ telnet www.linux-user.de 80 | tee file.html
Konvertieren der Datei "file.html" in eine normale Textdatei.
$ html2text -o file.txt file.html
Weblinks
Herausgeber | Sprache | Webseitentitel | Anmerkungen |
---|---|---|---|
Wikipedia | ger | Hypertext Transfer Protocolwbm | Enzyklopädischer Artikel |