Gemäß etablierter Schichtmodelle zur Klassifizierung von Netzprotokollen nach ihren einfacheren oder abstrakten Aufgabenstellungen wird HTTP der so genannten Applikationsschicht zugewiesen. Dies wird von den Anwenderprogrammen angegangen, im Falle von HTTP ist dies in der Regel ein Web-Browser. Die Applikationsschicht korrespondiert im ISOSchichtmodell mit der Ebene Sieben, wobei HTTP ein stateless Protokol ist. In der Regel können die über HTTP übertragenen Informationen auf allen im Netz laufenden Computern und Router eingesehen werden.
Allerdings kann die Übermittlung über HTTPS kodiert werden. HTTP ist durch die Ausweitung seiner Anforderungsmethoden, Kopfinformationen und Statusinformationen nicht auf Hyperlinks begrenzt, sondern wird immer häufiger zum Datenaustausch eingesetzt und ist die Basis des auf die Dateitransfers optimierten WebDAV-Protokolls. Für die Verständigung setzt HTTP auf ein verlässliches Übertragungsprotokoll, bei dem TCP in fast allen FÃ?llen eingesetzt wird.
In HTTP werden die Kommunikations-Einheiten zwischen Klient und Serverbetrieb als Messages bezeichnet, von denen es zwei verschiedene Typen gibt: die Anforderung vom Klienten an den Serverbetrieb und die Rückmeldung vom Serverbetrieb an den Klienten. Wird der Verweis auf die URL http://www.example.net/infotext. HTML in einem Webbrowser aktiv, wird die Anforderung, die Ressourcen /infotext.html zurückzugeben, an den Computer mit dem Rechnernamen www.example.net. gesendet.
Für die Übermittlung wird ein HTTP-GET-Request über TCP an den Standardport 80 des HTTP-Servers geschickt. Anforderung: Wenn der Link Zeichen beinhaltet, die in der Anforderung nicht zulässig sind, werden diese mit Prozentsatz verschlüsselt. Zusatzinformationen wie z. B. Browserinformationen, die gewünschte Landessprache, etc. können über den Kopf in jeder HTTP-Kommunikation übermittelt werden.
Wenn die Kopfzeile mit einer leeren Zeile (oder zwei aufeinander folgenden Zeilenenden) endet, schickt der Computer, der einen Webserver ausführt ( "auf Port 80"), eine HTTP-Antwort zurück. Die Übertragung von Daten erfolgt in der Regel in den Sprachen der Seitenbeschreibung wie (X)HTML und allen seinen Zusätzen, wie z.B. Bildern, Stylesheets (CSS), Skripten (JavaScript), etc. Grundsätzlich kann jede beliebige Akte in jedem gewünschten Dateiformat übergeben werden, wodurch die "Akte" auch dynamisiert werden kann und nicht als physikalische Akte auf dem Datenserver vorliegen muss (z.B. bei Verwendung von CGI, SSI, JSP, PHP oder ASP.NET).
Antwort: Der Datenserver gibt eine Fehlernachricht und einen Fehlermeldungscode zurück, wenn die Informationen aus irgendeinem Grunde nicht übertragen werden können, aber es werden Statuschlüssel auch bei erfolgreicher Anforderung benutzt, in diesem Fall (meist) 200 OK. Die exakte Reihenfolge dieses Prozesses (Request und Response) ist in der HTTP-Spezifikation definiert.
Als Gründer des Internets und ebenfalls entwickelter HTTP betrachtet, wird eine neue Basiskonfiguration vor jeder Anforderung hergestellt und nach dem Senden der Rückmeldung per Default durch den Webserver beendet. 2 Bei HTTP/1. 1 erlaubt ein zusätzlicher Header-Eintrag (Keepalive) einem Mandanten, den Willen zu äussern, keine Verbindungsaufnahme vorzunehmen, um die Verbindungsaufnahme wieder durchführen zu können (persistente Verbindung).
Ab HTTP/1.1 ist es möglich, Dateien abzurufen und zu transferieren. Web-Designer können ihre Webseiten mit der PUT-Methode über WebDAV unmittelbar auf dem webbasierten Rechner veröffentlichen und mit der DELETE-Methode können sie Dateien vom Rechner entfernen. HTTP/1.1 stellt auch eine TRACE-Methode zur Verfügung, um den Pfad zum Internetserver zu verfolgen und zu überprüfen, ob die Datenübertragung ordnungsgemäß erfolgt.
3. Google (SPDY) und Microsoft (HTTP Speed+Mobility)[4] waren die Haupttreiber dieser Entscheidung, jeder mit seinen eigenen Anträgen. Bei HTTP/2 soll die Übermittlung verkürzt und verbessert werden. Sie wird verwendet, um eine Ressourcen (z.B. eine Datei) vom Datenserver anzufordern, indem eine URI angegeben wird. In der URI können als Argument auch Content an den Datenserver übergeben werden, aber nach dem Standard sollte eine GET-Anforderung nur den Datenabruf beinhalten und sonst keine Wirkung haben (z.B. Datenänderung auf dem Datenserver oder Abmeldung).
Der URI ist je nach verwendetem Rechner limitiert und sollte aus Kompatibilitätsgründen 255 Byte nicht überschreiten. POST sendet abhängig von der physischen Ausrüstung des verwendeten Rechners unbegrenzt viele Datensätze zur Weiterverarbeitung an den Rechner, die als Nachrichteninhalt übermittelt werden und z.B. aus Name-Wert-Paaren aus einem HTML-Formular zusammengesetzt sein können.
So können neue Resourcen auf dem Datenserver angelegt oder vorhandene geändert werden. Darüber hinaus können bei dieser Übertragungsart auch wie im GET-Verfahren an den URI angehängt werden. Durch HEAD wird der Datenserver angewiesen, die selben HTTP-Header wie GET zu versenden, aber nicht der Nachrichtentext mit dem tatsächlichen Beleg.
LÖSCHEN lÖSCHT die spezifizierte Quelle auf dem Datenserver. Bei der Rückgabe von TRACE wird die vom Bediener empfangene Anforderung zurückgegeben. Auf diese Weise können Sie überprüfen, ob und wie die Anforderung auf dem Weg zum Datenserver geändert wurde - nützlich für das Debuggen von Anbindungen. Der Rückgabewert von Options enthält eine Auswahlliste der vom Datenserver unterstützen Verfahren und Eigenschaften.
Dabei kommen vor allem die HTTP-Request-Methoden GET, POST, PUT/PATCH und DELETE zum Einsatz. Das WebDAV ergänzt HTTP um die Verfahren PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK und UNLOCK. HTTP bietet dafür zwei Möglichkeiten: Die Angaben sind Teil der URL und werden daher beim Sichern oder Weiterleiten des Verweises beibehalten.
Mit HTTP-POST übertragene Informationen mit einem speziellen Anforderungstyp im HTTP-Nachrichtentext, so dass sie in der URL nicht ersichtlich sind. Die folgende oder eine vergleichbare Anforderung schickt der Webbrowser an den Server: Dies teilt dem Datenserver mit, dass der Benutzer die Artikelkatzen ansehen möchte. Die Serverin bearbeitet die Anforderung, schickt aber keine Dateien, sondern lenkt den Webbrowser mit einem Location-Header z.B. auf die richtige Page um:
Der Webbrowser folgt diesem Befehl und schickt z.B. aufgrund der neuen Information eine neue Anfrage: Außerdem beantwortet und zeigt der Datenserver z.B. die Artikelkatzen an: Nachteilig an dieser Vorgehensweise ist, dass die spezifizierten Kenngrößen mit der URL in der Regel in der History des Webbrowsers abgelegt werden und so personenbezogene Nutzerdaten ungewollt im Webbrowser abgelegt werden können.
Weil sich die Informationen nicht in der URL wiederfinden, kann POST zur Übertragung großer Mengen von Informationen, wie z. B. Bildern, eingesetzt werden. In diesem Beispiel wird der Beitrag cats erneut angefragt, aber der Webbrowser benutzt für eine POST-Anfrage einen geänderten HTML-Code (method="POST"). V::::: Der Datenserver erkennt dies ebenfalls und beantwortet mit dem nachfolgenden Text:
Jeder HTTP-Request wird vom Datenserver mit einem HTTP-Statuscode geantwortet. So gibt sie beispielsweise Auskunft darüber, ob die Anforderung korrekt verarbeitet wurde oder sagt dem Kunden im Falle eines Fehlers, wie z.B. dem Webbrowser, wo (z.B. Umleitung) oder wie (z.B. bei Authentifizierung) er die gewünschte Information auslesen kann.
Ixx - Information Die Prozessierung der Anforderung wird trotz der Rückmeldungen fortgesetzt. Diese Zwischenmeldung ist unter Umständen erforderlich, da viele Mandanten bei der Übermittlung oder Abarbeitung der Anforderung nach einer gewissen Zeit ( "Timeout") selbsttätig davon ausgehen, dass ein Irrtum vorliegt, und mit einer Fehlernachricht abtreiben. Die Anforderung wurde verarbeitet und die Beantwortung wird an den Antragsteller zurückgegeben.
Nachsendeauftrag Um eine reibungslose Abwicklung der Anforderung zu gewährleisten, sind weitere Maßnahmen seitens des Kunden notwendig. Durch die Reaktion des Bedieners lernt der Kunde im Ortsheader, wo sich die Akte jetzt aufhält. Bei der Verarbeitung der Anforderung ist ein Irrtum unter der Verantwortung des Kunden entstanden.
So tritt z. B. ein 404 auf, wenn ein nicht auf dem Datenserver vorhandenes Original angefordert wird. Eine 403 teilt dem Kunden mit, dass es nicht zulässig ist, das Original zurückzuholen. Es ist ein Serverfehler aufgetreten, der durch den Bediener verursacht wird. 501 besagt zum Beispiel, dass der Datenserver nicht über die Funktionalität (d.h. über die für die Bearbeitung der Anforderung notwendigen Programm- oder sonstigen Dateien) verfügt. In diesem Fall wird die Anforderung nicht bearbeitet.
Dabei wird geprüft, ob die Informationen verfügbar sind, oder dem Benutzer ein Dialogfeld angezeigt, in dem er Namen und Kennwort eingeben muss, und dieses an den Datenserver übertragen. Bei korrekten Eingaben wird die zugehörige Webseite an den Webbrowser geschickt. Danach wird die Authentisierung mit dem Autorisierungskopf in der folgenden Weise gesendet: Benutzername:Passwort Base64-kodiert an den Servers.
Auszug Zugangsauthentifizierung Mit Auszug Zugangsauthentifizierung schickt der Datenserver zudem eine speziell generierte Zufallszeichenkette (nonce) mit dem WWW-Authentifizierungskopf. Mithilfe des Browsers wird der Hash-Code aller erfassten Informationen (Benutzername, Kennwort, empfangene Zeichenkette, HTTP-Methode und angeforderte URI) errechnet und zusammen mit dem Benutzernamen und der Zufallszeichenkette an den Datenserver im Autorisierungskopf zurückgesendet, wobei er ihn mit der selbst berechne temp.
Für einen Hacker ist das Hören der Nachricht hier nutzlos, da die Informationen durch die Chiffrierung mit dem Hash-Code nicht rekonstruiert werden können und für jeden Request unterschiedlich sind. Der Kunde muss angeben, welche Komprimierungsmethoden er bei der Beantragung einer Requests durchlaufen kann. Dann kann der Datenserver die Response mit einer vom Kunden unterstützen Methode zusammendrücken und gibt die im Kopf der Inhaltskodierung verwendete Komprimierungsmethode an.
Die HTTP-Komprimierung speichert insbesondere bei Textdaten (HTML, CSS, Javascript) beträchtliche Mengen an Informationen, da diese gut komprimierbar sind. Für bereits komprimierte Dateien (z.B. gebräuchliche Bild-, Ton- und Videoformate) ist die (Re-)Kompression unbrauchbar und wird daher meist nicht angewendet. Das textbasierte Protokol HTTP wird nicht nur für die Übermittlung von Web-Seiten eingesetzt, es kann auch in unabhängigen Anwendungen, den Web-Diensten, eingesetzt werden.
Springen Sie auf Tim Berners-Lee: The Original HTTP as definiert in 1991. In: w3. org, abrufbar am 11. Oktober 2010. Springen Sie auf RFCs für die Verwendung von RSS-Feeds für die Verwendung von RSS-Feeds. xx, Presseinformation 14:23 Uhr am 14. Dezember 2015. Jump up Christian Kirsch: Microsoft stellt einen eigenen Antrag für HTTP vor. heise.de, 28. Dezember 2012, abrufbar am 16. August 2012. jump up ? Die neue Protokollentwicklung pcwelt.de, 31. Jänner 2016, abrufbar am 22. Dezember 2018. Jump up M. Beelshe, R. Peon, M. Thomson: Hypertext Transport Protokollversion 2, Nutzung von TLS-Funktionen.