Hypertext Transfer Protocol: Unterschied zwischen den Versionen

Aus Mikiwiki
Wechseln zu: Navigation, Suche
 
(3 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 Kommunikatiosnpartner, darauf in angemessener Weise zu reagieren.
+
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 gerade ideal, denn sobald durch Paketverluste Aussetzer entstehen, schaukelt sich der Effekt noch hoch, weil die verlorenen Pakete neu übertragen werden.
+
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 Bytes 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.
+
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 280: Zeile 280:
  
 
  $ <b>html2text -o file.txt file.html</b>
 
  $ <b>html2text -o file.txt file.html</b>
 +
 +
== Weblinks ==
  
 
{{Weblinks}}
 
{{Weblinks}}
 
{{url_dewikipedia|Hypertext_Transfer_Protocol|Hypertext Transfer Protocol}}
 
{{url_dewikipedia|Hypertext_Transfer_Protocol|Hypertext Transfer Protocol}}
{{url|GB|Netcraft Ltd.|eng|http://news.netcraft.com/|Netcraft|Statistiken zum WWW}}
 
 
{{Fuss}}
 
{{Fuss}}
  

Aktuelle Version vom 10. Februar 2013, 13: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
country DE.gif Wikipedia ger Hypertext Transfer Protocolwbm Enzyklopädischer Artikel