Hypertext Transfer Protocol: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
K Textersetzung - „Kryptografies“ durch „Kryptografie“
 
(149 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''topic''' kurze Beschreibung
'''Hypertext Transfer Protocol''' (HTTP) - Protokoll zur Übertragung von Daten auf der Anwendungsschicht
 
== Beschreibung ==
== Beschreibung ==
Das '''Hypertext Transfer Protocol''' ('''HTTP''') ist ein
; Hypertext-Übertragungsprotokoll
* [[Zustandslosigkeit|zustandsloses]] [[Netzwerkprotokoll|Protokoll]]
* Hypertext Transfer Protocol (HTTP)
* zur Übertragung von [[Daten]] auf der [[OSI-Modell#Schicht 7 – Anwendungsschicht (Application Layer)|Anwendungsschicht]]  
* Protokoll zur Übertragung von Daten auf der Anwendungsschicht
* über ein [[Rechnernetz]]
* Übertragung von [[Daten]] auf der [[OSI-Modell#Schicht 7 – Anwendungsschicht (Application Layer)|Anwendungsschicht]] über ein [[Rechnernetz]]
* 1991 eingeführt
* 1991 eingeführt
* Es wird hauptsächlich eingesetzt, um [[Webseite]]n (Hypertext-Dokumente) aus dem [[World Wide Web]] (WWW) in einen [[Webbrowser]] zu laden.
* [[#Zustandslos | Zustandslos]]
* Es ist jedoch nicht prinzipiell darauf beschränkt und auch als allgemeines Dateiübertragungsprotokoll sehr verbreitet.


; Webseiten
* Es wird hauptsächlich eingesetzt, um [[Webseite]]n (Hypertext-Dokumente) aus dem [[World Wide Web]] (WWW) in einen [[Webbrowser]] zu laden
* Es ist jedoch nicht prinzipiell darauf beschränkt und auch als allgemeines Dateiübertragungsprotokoll sehr verbreitet
; Standardisierung
; HTTP wurde von der [[Internet Engineering Task Force]] (IETF) und dem [[World Wide Web Consortium]] (W3C) standardisiert
; HTTP wurde von der [[Internet Engineering Task Force]] (IETF) und dem [[World Wide Web Consortium]] (W3C) standardisiert
* Aktuelle Version ist HTTP/3, welche als [[Request for Comments|RFC]] 9114 im Juni 2022 veröffentlicht wurde.<ref>[https://datatracker.ietf.org/doc/html/rfc9114 HTTP/3], auf datatracker.ietf.org</ref><ref name=heise_7135411 />
* Aktuelle Version ist HTTP/3, welche als [[Request for Comments|RFC]] 9114 im Juni 2022 veröffentlicht wurde
* Die Weiterentwicklung wird von der HTTP-Arbeitsgruppe der IETF (HTTPbis) organisiert.
* Die Weiterentwicklung wird von der HTTP-Arbeitsgruppe der IETF (HTTPbis) organisiert


; Ergänzende und aufbauende Standards  
; Ergänzende und aufbauende Standards
* [[Hypertext Transfer Protocol Secure|HTTPS]] für die Verschlüsselung übertragener Inhalte  
* [[Hypertext Transfer Protocol Secure|HTTPS]] für die Kryptografie übertragener Inhalte
* [[WebDAV]] Übertragungsprotokoll
* [[WebDAV]] Übertragungsprotokoll


== Eigenschaften ==
=== Eigenschaften ===
Nach etablierten [[Schichtenmodell]]en zur Einordnung von Netzwerkprotokollen nach ihren grundlegenderen oder abstrakteren Aufgaben wird HTTP der sogenannten Anwendungsschicht zugeordnet.
Nach etablierten [[Schichtenmodell]]en zur Einordnung von Netzwerkprotokollen nach ihren grundlegenderen oder abstrakteren Aufgaben wird HTTP der sogenannten Anwendungsschicht zugeordnet
* Diese wird von den [[Anwendungsprogramm]]en angesprochen, im Fall von HTTP ist das meist ein Webbrowser.
* Diese wird von den [[Anwendungsprogramm]]en angesprochen, im Fall von HTTP ist das meist ein Webbrowser
* Im [[OSI-Modell|ISO/OSI-Schichtenmodell]] entspricht die Anwendungsschicht der 7. Schicht.
* Im [[OSI-Modell|ISO/OSI-Schichtenmodell]] entspricht die Anwendungsschicht der 7. Schicht


HTTP ist ein [[Zustandslosigkeit|zustandsloses]] Protokoll.
==== Zustandslos ====
* Informationen aus früheren Anforderungen gehen verloren.
HTTP ist ein [[Zustandslosigkeit|zustandsloses]] Protokoll
* Ein zuverlässiges Mitführen von Sitzungsdaten kann erst auf der Anwendungsschicht durch eine [[Sitzung (Informatik)|Sitzung]] über einen [[Sitzungsbezeichner]] implementiert werden.
* Informationen aus früheren Anforderungen gehen verloren
Über [[HTTP-Cookie|Cookies]] in den Header-Informationen können aber Anwendungen realisiert werden, die Statusinformationen (Benutzereinträge, Warenkörbe) zuordnen können.
* Ein zuverlässiges Mitführen von Sitzungsdaten kann erst auf der Anwendungsschicht durch eine [[Sitzung (Informatik)|Sitzung]] über einen [[Sitzungsbezeichner]] implementiert werden
* Dadurch werden [[Webanwendung|Anwendungen]] möglich, die Status- beziehungsweise [[Sitzung (Informatik)|Sitzungseigenschaften]] erfordern.
* Auch eine Benutzer[[authentifizierung]] ist möglich.
* Bis HTTP/2 kann die Information, die über HTTP übertragen wird, normalerweise auf allen Rechnern und [[Router]]n gelesen werden, die im [[Rechnernetz|Netzwerk]] durchlaufen werden. Über [[Hypertext Transfer Protocol Secure|HTTPS]] jedoch kann die Übertragung [[Verschlüsselung|verschlüsselt]] erfolgen.
* HTTP/3 baut auf [[QUIC]] auf, das eine [[Transport Layer Security|TLS]] Kodierung erzwingt.


Durch Erweiterung seiner Anfragemethoden, [[Header]]-Informationen und Statuscodes ist HTTP nicht auf [[Hypertext]] beschränkt, sondern wird zunehmend zum Austausch beliebiger Daten verwendet, außerdem ist es Grundlage des auf Dateiübertragung spezialisierten Protokolls [[WebDAV]].
==== Cookies ====
* Zur [[Kommunikation]] ist HTTP auf ein [[Zuverlässigkeit (Telekommunikation)|zuverlässiges]] [[Transportprotokoll]] angewiesen, wofür bis zu HTTP/2 in nahezu allen Fällen [[Transmission Control Protocol|TCP]] verwendet wird.
Über [[HTTP-Cookie|Cookies]] in den Header-Informationen können aber Anwendungen realisiert werden, die Statusinformationen (Benutzereinträge, Warenkörbe) zuordnen können
* HTTP/3 setzt auf QUIC auf, welches seinerseits auf UDP basiert.
* Dadurch werden [[Webanwendung|Anwendungen]] möglich, die Status- beziehungsweise [[Sitzung (Informatik)|Sitzungseigenschaften]] erfordern
* Auch eine Benutzer[[authentifizierung]] ist möglich
* Bis HTTP/2 kann die Information, die über HTTP übertragen wird, normalerweise auf allen Rechnern und [[Router]]n gelesen werden, die im [[Rechnernetz|Netzwerk]] durchlaufen werden.
* Über [[Hypertext Transfer Protocol Secure|HTTPS]] jedoch kann die Übertragung [[Kryptografie|verschlüsselt]] erfolgen
* HTTP/3 baut auf [[QUIC]] auf, das eine [[Transport Layer Security|TLS]] Kodierung erzwingt


Derzeit werden hauptsächlich zwei Protokollversionen, HTTP/1.0 und HTTP/1.1, verwendet.
==== Methoden ====
Durch Erweiterung seiner Anfragemethoden, [[Header]]-Informationen und Statuscodes ist HTTP nicht auf [[Hypertext]] beschränkt, sondern wird zunehmend zum Austausch beliebiger Daten verwendet, außerdem ist es Grundlage des auf Dateiübertragung spezialisierten Protokolls [[WebDAV]]
* Zur [[Kommunikation]] ist HTTP auf ein [[Zuverlässigkeit (Telekommunikation)|zuverlässiges]] [[Transportprotokoll]] angewiesen, wofür bis zu HTTP/2 in nahezu allen Fällen [[Transmission Control Protocol|TCP]] verwendet wird
* HTTP/3 setzt auf QUIC auf, welches seinerseits auf UDP basiert
 
Derzeit werden hauptsächlich zwei Protokollversionen, HTTP/1.0 und HTTP/1.1, verwendet
* Neuere Versionen alltäglicher Webbrowser wie [[Chromium (Browser)|Chromium]], [[Google Chrome|Chrome]], [[Opera (Browser)|Opera]], [[Mozilla Firefox|Firefox]], [[Microsoft Edge|Edge]] und [[Internet Explorer]] sind darüber hinaus bereits kompatibel zu der neu eingeführten Version 2 des HTTP (HTTP/2)
* Neuere Versionen alltäglicher Webbrowser wie [[Chromium (Browser)|Chromium]], [[Google Chrome|Chrome]], [[Opera (Browser)|Opera]], [[Mozilla Firefox|Firefox]], [[Microsoft Edge|Edge]] und [[Internet Explorer]] sind darüber hinaus bereits kompatibel zu der neu eingeführten Version 2 des HTTP (HTTP/2)


== Aufbau ==
==== Aufbau ====
Die Kommunikationseinheiten in HTTP zwischen [[Client]] und [[Server]] werden als ''Nachrichten'' bezeichnet, von denen es zwei unterschiedliche Arten gibt: die ''Anfrage'' (englisch ''Request'') vom Client an den Server und die ''Antwort'' (englisch ''Response'') als Reaktion darauf vom Server zum Client.
Die Kommunikationseinheiten in HTTP zwischen [[Client]] und [[Server]] werden als ''Nachrichten'' bezeichnet, von denen es zwei unterschiedliche Arten gibt: die ''Anfrage'' (englisch ''Request'') vom Client an den Server und die ''Antwort'' (englisch ''Response'') als Reaktion darauf vom Server zum Client


Jede Nachricht besteht dabei aus zwei Teilen, dem Nachrichtenkopf (englisch ''Message Header'', kurz: ''Header'' oder auch HTTP-Header genannt) und dem Nachrichtenrumpf (englisch ''Message Body'', kurz: ''Body'').
Jede Nachricht besteht dabei aus zwei Teilen
* Der Nachrichtenkopf enthält Informationen über den Nachrichtenrumpf wie etwa verwendete Kodierungen oder den Inhaltstyp, damit dieser vom Empfänger korrekt interpretiert werden kann (''siehe Hauptartikel: [[Liste der HTTP-Headerfelder]]'').
{| class="wikitable options"
* Der Nachrichtenrumpf enthält schließlich die Nutzdaten.
|-
! Option !! !! Beschreibung
|-
| Nachrichtenkopf || Message Header, Header, HTTP-Header || Informationen über den Nachrichtenrumpf, damit dieser vom Empfänger korrekt interpretiert werden kann
* Verwendete Kodierung
* Inhaltstyp
* siehe [[Liste der HTTP-Headerfelder]]
|-
| Nachrichtenrumpf || Message Body, Body || Nutzdaten
|}


== Funktionsweise ==
== Funktion ==
[[Datei:HTTP-Anfrage.svg|mini|hochkant=1.8|Beispiel einer Transaktion, ausgeführt mit [[Telnet]] ]]
[[Datei:HTTP-Anfrage.svg|mini|400px|Transaktion mit [[Telnet]] ]]
Wenn in einem Web Browser der [[Hyperlink|Link]] zur URL ''<nowiki>http://www.example.net/infotext.html</nowiki>'' aktiviert wird, so wird an den Rechner mit dem Hostnamen ''www.example.net'' die Anfrage gerichtet, die Ressource ''/infotext.html'' zurückzusenden.
Wenn in einem Web Browser der [[Hyperlink|Link]] zur URL ''<nowiki>http://www.example.net/infotext.html</nowiki>'' aktiviert wird, so wird an den Rechner mit dem Hostnamen ''www.example.net'' die Anfrage gerichtet, die Ressource ''/infotext.html'' zurückzusenden


Der Name ''www.example.net'' wird dabei zuerst über das [[Domain Name System|DNS]]-Protokoll in eine [[IP-Adresse]] umgesetzt.
Der Name ''www.example.net'' wird dabei zuerst über das [[Domain Name System|DNS]]-Protokoll in eine [[IP-Adresse]] umgesetzt
* Zur Übertragung wird über TCP auf den Standard-[[Port (Protokoll)|Port]] 80 des HTTP-Servers eine HTTP-GET-Anforderung gesendet.
* Zur Übertragung wird über TCP auf den Standard-[[Port (Protokoll)|Port]] 80 des HTTP-Servers eine HTTP-GET-Anforderung gesendet
 
Anfrage:


=== Anfrage ===
  GET /infotext.html HTTP/1.1
  GET /infotext.html HTTP/1.1
  Host: www.example.net
  Host: www.example.net


Enthält der Link Zeichen, die in der Anfrage nicht erlaubt sind, werden diese [[URL Encoding|%-kodiert]].
Enthält der Link Zeichen, die in der Anfrage nicht erlaubt sind, werden diese [[URL Encoding|%-kodiert]]
* Zusätzliche Informationen wie Angaben über den Browser, zur gewünschten Sprache etc.
* Zusätzliche Informationen wie Angaben über den Browser, zur gewünschten Sprache etc
* können über den [[Liste der HTTP-Headerfelder|Header]] (Kopfzeilen) in jeder HTTP-Kommunikation übertragen werden.
* können über den [[Liste der HTTP-Headerfelder|Header]] (Kopfzeilen) in jeder HTTP-Kommunikation übertragen werden
* Mit dem „Host“-Feld lassen sich verschiedene DNS-Namen unter der gleichen IP-Adresse unterscheiden.
* Mit dem „Host“-Feld lassen sich verschiedene DNS-Namen unter der gleichen IP-Adresse unterscheiden
* Unter HTTP/1.0 ist es optional, unter HTTP/1.1 jedoch erforderlich.
* Unter HTTP/1.0 ist es optional, unter HTTP/1.1 jedoch erforderlich
* Sobald der Header mit einer Leerzeile (beziehungsweise zwei aufeinanderfolgenden Zeilenenden) abgeschlossen wird, sendet der Rechner, der einen Web-Server (an Port 80) betreibt, seinerseits eine HTTP-Antwort zurück.
* Sobald der Header mit einer Leerzeile (beziehungsweise zwei aufeinanderfolgenden Zeilenenden) abgeschlossen wird, sendet der Rechner, der einen Web-Server (an Port 80) betreibt, seinerseits eine HTTP-Antwort zurück
* Diese besteht aus den Header-Informationen des Servers, einer Leerzeile und dem tatsächlichen Inhalt der Nachricht, also dem Dateiinhalt der ''infotext.html''-Datei. Übertragen werden Dateien normalerweise in Seitenbeschreibungssprachen wie ([[Extensible Hypertext Markup Language|X]])[[Hypertext Markup Language|HTML]] und alle ihre Ergänzungen, zum Beispiel Bilder, Stylesheets ([[Cascading Style Sheets|CSS]]), Skripte ([[JavaScript]]) usw., die meistens von einem Browser in einer lesbaren Darstellung miteinander verbunden werden.
* Diese besteht aus den Header-Informationen des Servers, einer Leerzeile und dem tatsächlichen Inhalt der Nachricht, also dem Dateiinhalt der ''infotext.html''-Datei. Übertragen werden Dateien normalerweise in Seitenbeschreibungssprachen wie ([[Extensible Hypertext Markup Language|X]])[[Hypertext Markup Language|HTML]] und alle ihre Ergänzungen, zum Beispiel Bilder, Stylesheets ([[Cascading Style Sheets|CSS]]), Skripte ([[JavaScript]]) usw., die meistens von einem Browser in einer lesbaren Darstellung miteinander verbunden werden
* Prinzipiell kann jede Datei in jedem beliebigen Format übertragen werden, wobei die „Datei“ auch dynamisch generiert werden kann und nicht auf dem Server als physische Datei vorhanden zu sein braucht (zum Beispiel bei Anwendung von [[Common Gateway Interface|CGI]], [[Server Side Includes|SSI]], [[JavaServer Pages|JSP]], [[PHP]] oder [[ASP.NET]]).
* Prinzipiell kann jede Datei in jedem beliebigen Format übertragen werden, wobei die „Datei“ auch dynamisch generiert werden kann und nicht auf dem Server als physische Datei vorhanden zu sein braucht (zum Beispiel bei Anwendung von [[Common Gateway Interface|CGI]], [[Server Side Includes|SSI]], [[JavaServer Pages|JSP]], [[PHP]] oder [[ASP.NET]])
Jede Zeile im Header wird durch den [[Zeilenumbruch]] <[[Wagenrücklauf|CR]]><[[Zeilenvorschub|LF]]> abgeschlossen.
Jede Zeile im Header wird durch den [[Zeilenumbruch]] <[[Wagenrücklauf|CR]]><[[Zeilenvorschub|LF]]> abgeschlossen
* Die Leerzeile nach dem Header darf nur aus <nowiki><CR><LF></nowiki>, ohne eingeschlossenes [[Leerzeichen]], bestehen.
* Die Leerzeile nach dem Header darf nur aus <nowiki><CR><LF></nowiki>, ohne eingeschlossenes [[Leerzeichen]], bestehen
 
=== Antwort ===


Antwort:
  HTTP/1.1 200 OK
  HTTP/1.1 200 OK
  Server: [[Apache HTTP Server|Apache]]/1.3.29 ([[Unix]]) PHP/4.3.4
  Server: [[Apache HTTP Server|Apache]]/1.3.29 ([[Unix]]) PHP/4.3.4
Zeile 75: Zeile 94:
  Connection: close
  Connection: close
  [[Content-Type]]: text/html
  [[Content-Type]]: text/html
''(Inhalt von infotext.html)''
''(Inhalt von infotext.html)''


Der Server sendet eine [[Fehlerseite|Fehlermeldung]] sowie einen [[HTTP-Statuscode|Fehlercode]] zurück, wenn die Information aus irgendeinem Grund nicht gesendet werden kann, allerdings werden auch dann Statuscodes verwendet, wenn die Anfrage erfolgreich war, in dem Falle (meistens) 200 OK.
; Status
* Der genaue Ablauf dieses Vorgangs (Anfrage und Antwort) ist in der HTTP-Spezifikation festgelegt.
Der Server sendet eine [[Fehlerseite|Fehlermeldung]] sowie einen [[HTTP-Statuscode|Fehlercode]] zurück, wenn die Information aus einem Grund nicht gesendet werden kann, allerdings werden auch dann Statuscodes verwendet, wenn die Anfrage erfolgreich war, in dem Falle (meistens) 200 OK
* Der genaue Ablauf dieses Vorgangs (Anfrage und Antwort) ist in der HTTP-Spezifikation festgelegt
 
{| class="wikitable big options"
|-
| [[Hypertext Transfer Protocol/Methoden|Methoden]] ||
|-
| [[HTTP/Statuscode|Statuscode]] ||
|-
| [[HTTP/Authentifizierung|Authentifizierung]] ||
|-
| [[HTTP/Kompression|Kompression]] ||
|}


== Versionen ==
== Versionen ==
{| class="wikitable sortable options big"
|-
! Version !! Beschreibung
|-
| [[#HTTP/0.9|HTTP/0.9]] ||
|-
| [[#HTTP/1.0|HTTP/1.0]] ||
|-
| [[#HTTP/1.1|HTTP/1.1]] ||
|-
| [[#HTTP/2|HTTP/2]] ||
|-
| [[#HTTP/3|HTTP/3]] ||
|}
=== HTTP/0.9 ===
=== HTTP/0.9 ===
[[Datei:Tim Berners-Lee closeup.jpg|mini|hochkant=0.7|Sir Tim Berners-Lee gilt als Begründer des Webs und entwickelte auch HTTP mit.]]
[[Datei:Tim Berners-Lee closeup.jpg|mini|150px|Sir Tim Berners-Lee gilt als Begründer des Webs und entwickelte auch HTTP mit]]
Ab 1989 entwickelten [[Tim Berners-Lee]] und sein Team am [[CERN]], dem [[Europäische Union|europäischen]] Kernforschungszentrum in der Schweiz, das Hypertext Transfer Protocol, zusammen mit den Konzepten [[Uniform Resource Locator|URL]] und [[Hypertext Markup Language|HTML]], womit die Grundlagen des World Wide Web geschaffen wurden. Erste Ergebnisse dieser Bemühungen war 1991 die Version HTTP 0.9.<ref name="HTTP0.9" />
Ab 1989 entwickelten [[Tim Berners-Lee]] und sein Team am [[CERN]], dem [[Europäische Union|europäischen]] Kernforschungszentrum in der Schweiz, das Hypertext Transfer Protocol, zusammen mit den Konzepten [[Uniform Resource Locator|URL]] und [[Hypertext Markup Language|HTML]], womit die Grundlagen des World Wide Web geschaffen wurden. Erste Ergebnisse dieser Bemühungen war 1991 die Version HTTP 0.9


=== HTTP/1.0 ===
=== HTTP/1.0 ===
Die im Mai 1996 als RFC 1945 ([[Request for Comments]] Nr. 1945) publizierte Anforderung ist als HTTP/1.0 bekannt geworden.
Die im Mai 1996 als RFC 1945 ([[Request for Comments]] Nr. 1945) publizierte Anforderung ist als HTTP/1.0 bekannt geworden
Bei HTTP/1.0 wird vor jeder Anfrage eine neue [[Transmission Control Protocol|TCP]]-Verbindung aufgebaut und nach Übertragung der Antwort standardmäßig vom Server wieder geschlossen.
Bei HTTP/1.0 wird vor jeder Anfrage eine neue [[Transmission Control Protocol|TCP]]-Verbindung aufgebaut und nach Übertragung der Antwort standardmäßig vom Server 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.
* 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


=== HTTP/1.1 ===
=== HTTP/1.1 ===
1999 wurde eine zweite Anforderung als RFC 2616 publiziert, die den HTTP/1.1-Standard wiedergibt.<ref name="RFC2616" />
1999 wurde eine zweite Anforderung als RFC 2616 publiziert, die den HTTP/1.1-Standard wiedergibt
Bei HTTP/1.1 kann ein Client durch einen zusätzlichen Headereintrag ''([[Keepalive]])'' den Wunsch äußern, keinen Verbindungsabbau durchzuführen, um die Verbindung erneut nutzen zu können (persistent connection).
Bei HTTP/1.1 kann ein Client durch einen zusätzlichen Headereintrag ''([[Keepalive]])'' den Wunsch äußern, keinen Verbindungsabbau durchzuführen, um die Verbindung erneut nutzen zu können (persistent connection)
* Die Unterstützung auf Serverseite ist jedoch optional und kann in Verbindung mit Proxys Probleme bereiten.
* Die Unterstützung auf Serverseite ist jedoch optional und kann in Verbindung mit Proxys Probleme bereiten
* Mittels [[HTTP-Pipelining]] können in der Version 1.1 mehrere Anfragen und Antworten pro TCP-Verbindung gesendet werden.
* Mittels [[HTTP-Pipelining]] können in der Version 1.1 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.
* Für das HTML-Dokument mit zehn Bildern wird so nur eine TCP-Verbindung benötigt
* Da die Geschwindigkeit von TCP-Verbindungen zu Beginn durch Verwendung des ''[[Slow Start|Slow-Start]]''-Algorithmus recht gering ist, wird so die Ladezeit für die gesamte Seite signifikant verkürzt.
* Da die Geschwindigkeit von TCP-Verbindungen zu Beginn durch Verwendung des ''[[Slow Start|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.
* Zusätzlich können bei HTTP/1.1 abgebrochene Übertragungen fortgesetzt werden


Eine Möglichkeit zum Einsatz von HTTP/1.1 in Chats ist die Verwendung des [[Internet Media Type|MIME-Typs]] ''multipart/replace'', bei dem der Browser nach Senden eines ''Boundary''-Codes und eines neuerlichen ''Content-Length''-Headerfeldes sowie eines neuen ''Content-Type''-Headerfeldes den Inhalt des Browserfensters neu aufbaut.
Eine Möglichkeit zum Einsatz von HTTP/1.1 in Chats ist die Verwendung des [[Internet Media Type|MIME-Typs]] ''multipart/replace'', bei dem der Browser nach Senden eines ''Boundary''-Codes und eines neuerlichen ''Content-Length''-Headerfeldes sowie eines neuen ''Content-Type''-Headerfeldes den Inhalt des Browserfensters neu aufbaut


Mit HTTP/1.1 ist es neben dem Abholen von Daten auch möglich, Daten zum Server zu übertragen.
Mit HTTP/1.1 ist es neben dem Abholen von Daten auch möglich, Daten zum Server zu übertragen
* Mit Hilfe der [[#PUT|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.
* Mit Hilfe der [[#PUT|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 der Weg zum Webserver verfolgt und überprüft werden kann, ob die Daten korrekt dorthin übertragen werden.
* Außerdem bietet HTTP/1.1 eine TRACE-Methode, mit der der Weg zum Webserver verfolgt und überprüft werden kann, ob die Daten korrekt dorthin übertragen werden
* Damit ergibt sich die Möglichkeit, den Weg zum Webserver über die verschiedenen [[Proxy (Rechnernetz)|Proxys]] hinweg zu ermitteln, ein [[traceroute]] auf Anwendungsebene.
* Damit ergibt sich die Möglichkeit, den Weg zum Webserver über die verschiedenen [[Proxy-Server|Proxys]] hinweg zu ermitteln, ein [[traceroute]] auf Anwendungsebene


Aufgrund von Unstimmigkeiten und Unklarheiten wurde 2007 eine Arbeitsgruppe gestartet, die die Spezifikation verbessern sollte.
Aufgrund von Unstimmigkeiten und Unklarheiten wurde 2007 eine Arbeitsgruppe gestartet, die die Spezifikation verbessern sollte
* Ziel war hier lediglich eine klarere Formulierung, neue Funktionen wurden nicht eingebaut.
* Ziel war hier lediglich eine klarere Formulierung, neue Funktionen wurden nicht eingebaut
* Dieser Prozess wurde 2014 beendet und führte zu sechs neuen RFCs:
 
; Dieser Prozess wurde 2014 beendet und führte zu sechs RFCs
* RFC 7230 – HTTP/1.1: Message Syntax and Routing
* RFC 7230 – HTTP/1.1: Message Syntax and Routing
* RFC 7231 – HTTP/1.1: Semantics and Content
* RFC 7231 – HTTP/1.1: Semantics and Content
Zeile 117: Zeile 164:


=== HTTP/2 ===
=== HTTP/2 ===
Im Mai 2015 wurde von der IETF HTTP/2 als Nachfolger von HTTP/1.1 verabschiedet.
Im Mai 2015 wurde von der IETF HTTP/2 als Nachfolger von HTTP/1.1 verabschiedet
* Der Standard ist durch RFC 7540 und RFC 7541 spezifiziert.<ref>[http://heise.de/-2650979 RFCs für HTTP/2 festgelegt und -geschrieben]. [[iX – Magazin für professionelle Informationstechnik|iX]], News-Meldung vom 15.
* Der Standard ist durch RFC 7540 und RFC 7541 spezifiziert. Die Entwicklung war maßgeblich von [[Google Inc.|Google]] ''([[SPDY]])'' und [[Microsoft]] ''(HTTP Speed+Mobility)'' mit jeweils eigenen Vorschlägen vorangetrieben worden
* Mai 2015 14:23 Uhr.</ref> Die Entwicklung war maßgeblich von [[Google Inc.|Google]] ''([[SPDY]])'' und [[Microsoft]] ''(HTTP Speed+Mobility)''<ref name="heise.2012-03-29" /> mit jeweils eigenen Vorschlägen vorangetrieben worden.
* Ein erster Entwurf, der sich weitgehend an SPDY anlehnte, war im November 2012 publiziert und seither in mehreren Schritten angepasst worden
* Ein erster Entwurf, der sich weitgehend an SPDY anlehnte, war im November 2012 publiziert und seither in mehreren Schritten angepasst worden.


Mit HTTP/2 soll die Übertragung beschleunigt und optimiert werden.<ref name="heise.2009-11-13" /> Dabei soll der neue Standard jedoch vollständig abwärtskompatibel zu HTTP/1.1 sein.
Mit HTTP/2 soll die Übertragung beschleunigt und optimiert werden. Dabei soll der neue Standard jedoch vollständig abwärtskompatibel zu HTTP/1.1 sein


Wichtige neue Möglichkeiten sind
; Wichtige neue Möglichkeiten sind
* die Möglichkeit des Zusammenfassens mehrerer Anfragen,
* die Möglichkeit des Zusammenfassens mehrerer Anfragen
* weitergehende [[Datenkompression]]smöglichkeiten,
* weitergehende [[Datenkompression]]smöglichkeiten
* die binär kodierte Übertragung von Inhalten und
* die binär kodierte Übertragung von Inhalten und
* Server-initiierte Datenübertragungen (push-Verfahren),
* Server-initiierte Datenübertragungen (push-Verfahren)
* einzelne Streams lassen sich priorisieren.
* einzelne Streams können priorisiert werden


Eine Beschleunigung ergibt sich hauptsächlich aus der neuen Möglichkeit des Zusammenfassens ([[Multiplexverfahren|Multiplex]]) mehrerer Anfragen, um sie über eine Verbindung abwickeln zu können.
; Beschleunigung
Die [[Datenkompression]] kann nun (mittels neuem Spezialalgorithmus namens HPACK<ref name="HPACK" />) auch Kopfdaten mit einschließen.
Eine Beschleunigung ergibt sich hauptsächlich aus der neuen Möglichkeit des Zusammenfassens ([[Multiplexverfahren|Multiplex]]) mehrerer Anfragen, um sie über eine Verbindung abwickeln zu können
Inhalte können binär kodiert übertragen werden.
* Die [[Datenkompression]] kann nun (mittels neuem Spezialalgorithmus namens HPACK) auch Kopfdaten einschließen
Um nicht auf serverseitig vorhersehbare Folgeanforderungen vom Client warten zu müssen, können Datenübertragungen teilweise vom Server initiiert werden (push-Verfahren).
* Inhalte können binär kodiert übertragen werden
Durch die Verwendung von HTTP/2 können Webseitenbetreiber die Latenz zwischen Client und Server verringern und die Netzwerkhardware entlasten.<ref>{{Internetquelle |url=https://www.pcwelt.de/ratgeber/HTTP-2-schneller-surfen-mit-neuer-Protokollversion-Browser-und-Server-9775544.html |titel=HTTP/2 - schneller surfen mit neuer Protokollversion |hrsg=pcwelt.de |datum=2016-01-30 |abruf=2018-02-21}}</ref>
* Um nicht auf serverseitig vorhersehbare Folgeanforderungen vom Client warten zu müssen, können Datenübertragungen teilweise vom Server initiiert werden (push-Verfahren)
* Durch die Verwendung von HTTP/2 können Webseitenbetreiber die Latenz zwischen Client und Server verringern und die Netzwerkhardware entlasten


Die ursprünglich geplante Option, dass HTTP/2 standardmäßig [[Transport Layer Security|TLS]] nutzt, wurde nicht umgesetzt.
Die ursprünglich geplante Option, dass HTTP/2 standardmäßig [[Transport Layer Security|TLS]] nutzt, wurde nicht umgesetzt
* Allerdings kündigten die Browser-Hersteller Google und Mozilla an, dass ihre Webbrowser nur verschlüsselte HTTP/2-Verbindungen unterstützen werden.
* Allerdings kündigten die Browser-Hersteller Google und Mozilla an, dass ihre Webbrowser nur verschlüsselte HTTP/2-Verbindungen unterstützen werden
* Dafür ist [[ALPN]] eine Verschlüsselungs-Erweiterung, die TLSv1.2 oder neuer braucht.<ref>{{Internetquelle |autor=M. Belshe, R. Peon, M. Thomson |titel=Hypertext Transfer Protocol Version 2, Use of TLS Features |url=https://http2.github.io/http2-spec/#TLSUsage |abruf=2015-02-10 |archiv-url=https://web.archive.org/web/20130715004452/https://http2.github.io/http2-spec/#TLSUsage |archiv-datum=2013-07-15 |offline=ja |archiv-bot=2022-11-16 16:22:09 InternetArchiveBot }}</ref>
* Dafür ist [[ALPN]] eine Kryptografie-Erweiterung, die TLSv1.2 oder neuer benötigt


HTTP/2 wird von den meisten Browsern unterstützt, darunter Google Chrome (inkl. Chrome unter iOS und Android) ab Version 41, Mozilla Firefox ab Version 36,<ref name="Firefox 36">[http://www.admin-magazin.de/News/Firefox-36-implementiert-HTTP-2 Firefox 36 implementiert HTTP/2]</ref> Internet Explorer 11 unter Windows 10, Opera ab Version 28 (sowie Opera Mobile ab Version 24) und Safari ab Version 8.
; Unterstütztung
HTTP/2 wird von den meisten Browsern unterstützt, darunter Google Chrome (inkl. Chrome unter iOS und Android) ab Version 41, Mozilla Firefox ab Version 36, Internet Explorer 11 unter Windows 10, Opera ab Version 28 (sowie Opera Mobile ab Version 24) und Safari ab Version 8


=== HTTP/3 ===
=== HTTP/3 ===
[[Datei:HTTP-2 vs. HTTP-3 Protocol Stack.svg|mini]]
[[Datei:HTTP-2 vs. HTTP-3 Protocol Stack.svg|mini|200px]]
; Im Juni 2022 wurde HTTP/3 als RFC 9114 standardisiert.
[[QUIC]] setzt nicht mehr auf das verbindungsorientierte [[TCP/IP-Netzwerk|TCP]], sondern auf das verbindungslose [[User Datagram Protocol]] (UDP)
* Auch bei dem darauf aufbauenden HTTP/3 werden Datenströme getrennt verarbeitet
* Geht ein Paket unterwegs verloren, betrifft es nicht mehr alle Datenströme, wie es bei TCP der Fall ist
* Bei HTTP/3 wird der betroffene Strom warten, bis das fehlende Paket eintrifft
* HTTP/3 ist generell verschlüsselt und verspricht deutliche Geschwindigkeitsvorteile


; Im November 2018 wurde von der [[Internet Engineering Task Force|IETF]] beschlossen, dass HTTP/3 [[QUIC]] verwenden solle
; Entwicklung
Im Juni 2022 wurde HTTP/3 als RFC 9114 standardisiert
* Im November 2018 wurde von der [[Internet Engineering Task Force|IETF]] beschlossen, dass HTTP/3 [[QUIC]] verwenden solle
* Google arbeitet schon seit 2012 an einer Alternative unter dem Namen [[QUIC]]


; Google arbeitet schon seit 2012 an einer Alternative unter dem Namen [[QUIC]]
Google Chrome Canary war ab Mitte 2019 der erste verfügbare Browser, der eine experimentelle #QUIC- und HTTP/3-Unterstützung integriert hatte. [[cURL]] zog bald nach
* QUIC setzt nicht mehr auf das verbindungsorientierte [[TCP/IP-Netzwerk|TCP]], sondern auf das verbindungslose [[User Datagram Protocol]] (UDP).
* Die Vorab-Versionen von [[Firefox]] (nightly und beta) versuchen seit April 2021 automatisch, '''HTTP/3''' zu verwenden, wenn es vom Webserver (derzeit z.B [[Google]] oder [[Facebook]]) angeboten wird
* Auch bei dem darauf aufbauenden HTTP/3 werden Datenströme getrennt verarbeitet.
* Webserver können die Unterstützung anzeigen, indem sie den [[Liste der HTTP-Headerfelder|Alt-Svc-Antwortheader]] verwenden oder die HTTP/3-Unterstützung mit einem [[Domain Name System|HTTPS-DNS-Eintrag]] ankündigen
* Geht ein Paket unterwegs verloren, betrifft es nicht mehr alle Datenströme, wie es bei TCP der Fall ist.  
* Sowohl der Client als auch der Server müssen dieselbe [[QUIC]]- und HTTP/3-Entwurfsversion unterstützen, um sich verbinden zu können
* Bei HTTP/3 wird der betroffene Strom warten, bis das fehlende Paket eintrifft.
* Firefox unterstützt beispielsweise derzeit die Entwürfe 27 bis 32 der Spezifikation, sodass der Server die Unterstützung einer dieser Versionen (z.&nbsp;B.&nbsp;„h3-32“) im Alt-Svc- oder HTTPS-Eintrag melden muss, damit Firefox versucht, QUIC und HTTP/3 mit diesem Server zu verwenden
* HTTP/3 ist generell verschlüsselt und verspricht deutliche Geschwindigkeitsvorteile.
* Beim Besuch einer solchen Website sollte in den Netzwerkanforderungsinformationen darauf hingewiesen werden, dass HTTP/3 verwendet wird


Google Chrome Canary war ab Mitte 2019 der erste verfügbare Browser, der eine experimentelle #QUIC- und HTTP/3-Unterstützung integriert hatte. [[cURL]] zog bald nach.
== Anhang ==
* Die Vorab-Versionen von [[Firefox]] (nightly und beta) versuchen seit April 2021 automatisch, '''HTTP/3''' zu verwenden, wenn es vom Webserver (derzeit z.B [[Google]] oder [[Facebook]]) angeboten wird.
=== Siehe auch ===
* Webserver können die Unterstützung anzeigen, indem sie den [[Liste der HTTP-Headerfelder|Alt-Svc-Antwortheader]] verwenden oder die HTTP/3-Unterstützung mit einem [[Domain Name System|HTTPS-DNS-Eintrag]] ankündigen.
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
* Sowohl der Client als auch der Server müssen dieselbe [[QUIC]]- und HTTP/3-Entwurfsversion unterstützen, um sich verbinden zu können.
----
* Firefox unterstützt beispielsweise derzeit die Entwürfe 27 bis 32 der Spezifikation, sodass der Server die Unterstützung einer dieser Versionen (z. B. „h3-32“) im Alt-Svc- oder HTTPS-Eintrag melden muss, damit Firefox versucht, QUIC und HTTP/3 mit diesem Server zu verwenden.
{{Special:PrefixIndex/HTTP}}
* Beim Besuch einer solchen Website sollte in den Netzwerkanforderungsinformationen darauf hingewiesen werden, dass HTTP/3 verwendet wird.


== HTTP-Methoden ==
==== Dokumentation ====
=== Anfrage ===
{| class="wikitable sortable options big"
{| class="wikitable sortable options"
|-
! Option !! Beschreibung
|-
| GET || ist die gebräuchlichste Methode.
* Mit ihr wird eine Ressource (zum Beispiel eine Datei) unter Angabe eines [[Uniform Resource Identifier|URI]] vom Server angefordert.
* Als Argumente in dem URI können auch Inhalte zum Server übertragen werden, allerdings soll laut Standard eine GET-Anfrage nur Daten abrufen und sonst keine Auswirkungen haben (wie Datenänderungen auf dem Server oder ausloggen). ''(siehe [[#HTTP GET|unten]])''
|-
| POST || schickt Daten (z. B. den Inhalt einer Datei) zur weiteren Verarbeitung zum Server, diese werden als Inhalt der Nachricht übertragen und können beispielsweise aus Name-Wert-Paaren bestehen, die aus einem HTML-Formular stammen.
* Es können so neue Ressourcen auf dem Server entstehen oder bestehende modifiziert werden.
* POST-Daten werden im Allgemeinen nicht von [[Cache]]s zwischengespeichert.
* Zusätzlich können bei dieser Art der Übermittlung auch Daten wie in der GET-Methode an den URI gehängt werden. ''(siehe [[#HTTP POST|unten]])''
|-
| HEAD || weist den Server an, die gleichen HTTP-Header wie bei GET, nicht jedoch den Nachrichtenrumpf mit dem eigentlichen Dokumentinhalt zu senden.
* So kann zum Beispiel schnell die Gültigkeit einer Datei im [[Browser-Cache]] geprüft werden, und Dateigrößen können im Voraus abgerufen und durch die Content-Length-Zeile erlesen werden.
|-
|-
| PUT || dient dazu, eine Ressource (zum Beispiel eine Datei) unter Angabe des Ziel-URIs auf einen Webserver hochzuladen.
! RFC !! Titel
* Besteht unter der angegebenen Ziel-URI bereits eine Ressource, wird diese ersetzt, ansonsten neu erstellt.
|-
|-
| PATCH || Ändert ein bestehendes Dokument ohne dieses wie bei PUT vollständig zu ersetzen.
| [https://www.rfc-editor.org/info/rfc2616 RFC 2616] ||HTTP/1.1
* Wurde durch RFC 5789 spezifiziert.
|-
|-
| DELETE || löscht die angegebene Ressource auf dem Server.
| [https://www.rfc-editor.org/info/rfc9113 RFC 9113] || HTTP/2
|-
| 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 [[Debugger|Debugging]] von Verbindungen.
|-
| OPTIONS || liefert eine Liste der vom Server unterstützten Methoden und Merkmale.
|-
| CONNECT || wird von Proxyservern implementiert, die in der Lage sind, [[Secure Sockets Layer|SSL]]-Tunnel zur Verfügung zu stellen.
|-
| [[Representational State Transfer|RESTful]] || Web Services verwenden die unterschiedlichen Anfragemethoden zur Realisierung von [[Webservice]]s.
* Insbesondere werden dafür die HTTP-Anfragemethoden GET, POST, PUT/PATCH und DELETE verwendet.
|}
 
[[WebDAV]] fügt folgende Methoden hinzu
''PROPFIND''
''PROPPATCH''
''MKCOL''
''COPY''
''MOVE''
''LOCK''
''UNLOCK''
 
=== Argumentübertragung ===
Häufig will ein Nutzer Informationen an eine Website senden.
* Dazu stellt HTTP prinzipiell zwei Möglichkeiten zur Verfügung:
; HTTP-GET
: Die Daten sind Teil der URL und bleiben deshalb beim Speichern oder der Weitergabe des Links erhalten.
* Sie müssen [[URL Encoding|URL-kodiert]] werden, das heißt reservierte Zeichen müssen mit „%&lt;[[Hexadezimalsystem|Hex-Wert]]&gt;“ und Leerzeichen mit „+“ dargestellt werden.
; HTTP-POST
: Übertragung der Daten mit einer speziell dazu vorgesehenen Anfrageart im HTTP-Nachrichtenrumpf, so dass sie in der URL nicht sichtbar sind.
 
====  HTTP GET ====
Hier werden die Parameter-Wertepaare durch das Zeichen ? in der [[Uniform Resource Locator|URL]] eingeleitet.
Oft wird diese Vorgehensweise gewählt, um eine Liste von Parametern zu übertragen, die die Gegenstelle bei der Bearbeitung einer Anfrage berücksichtigen soll.
* Häufig besteht diese Liste aus Wertepaaren, welche durch das &-Zeichen voneinander getrennt sind.
* Die jeweiligen Wertepaare sind in der Form ''Parametername=Parameterwert'' aufgebaut.
* Seltener wird das Zeichen ; zur Trennung von Einträgen der Liste benutzt.<ref name="HTML 4.01-B.2.2" />
 
Ein Beispiel: Auf der Startseite von Wikipedia wird in das Eingabefeld der Suche „Katzen“ eingegeben und auf die Schaltfläche „Artikel“ geklickt.
* Der Browser sendet die folgende oder eine ähnliche Anfrage an den Server:
<syntaxhighlight lang="text">
GET /wiki/Spezial:Search?search=Katzen&go=Artikel HTTP/1.1
Host: de.wikipedia.org
…
</syntaxhighlight>
 
Dem Wikipedia-Server werden zwei Wertepaare übergeben:
{| class="wikitable"
!Argument
!Wert
|-
|-
|search
| [https://www.rfc-editor.org/info/rfc9114 RFC 9114] || HTTP/3
|Katzen
|-
|-
|go
| [https://www.rfc-editor.org/info/rfc7541 RFC 7541] || Header Compression
|Artikel
|}
 
Diese Wertepaare werden in der Form
 
Parameter1=Wert1&Parameter2=Wert2
 
mit vorangestelltem ? an die geforderte Seite angehängt.
 
Dadurch erfährt der Server, dass der Nutzer den Artikel ''[[Katzen]]'' betrachten will.
* Der Server verarbeitet die Anfrage, sendet aber keine Datei, sondern leitet den Browser mit einem Location-[[Header]] zur richtigen Seite weiter, etwa mit:
<syntaxhighlight lang="http">
HTTP/1.0 302 Found
Date: Fri, 13 Jan 2006 15:12:44 GMT
Location: http://de.wikipedia.org/wiki/Katzen
…
</syntaxhighlight>
Der Browser befolgt diese Anweisung und sendet aufgrund der neuen Informationen eine neue Anfrage, etwa:
 
<syntaxhighlight lang="http">
GET /wiki/Katzen HTTP/1.1
Host: de.wikipedia.org
…
</syntaxhighlight>
 
Und der Server antwortet und gibt den Artikel ''Katzen'' aus, etwa:
 
<syntaxhighlight lang="http">
HTTP/1.1 200 OK
Date: Fri, 13 Jan 2006 15:12:48 GMT
Last-Modified: Tue, 10 Jan 2006 11:18:20 GMT
Content-Language: de
Content-Type: text/html; charset=utf-8
 
Die Katzen (Felidae) sind eine Familie aus der Ordnung der Raubtiere (Carnivora)
innerhalb der Überfamilie der Katzenartigen (Feloidea).
…
</syntaxhighlight>
 
Der Datenteil ist meist länger, hier soll nur das Protokoll betrachtet werden.
 
Nachteil dieser Methode ist, dass die angegebenen Parameter mit der URL meist in der Historie des Browsers gespeichert werden und so persönliche Daten unbeabsichtigt im Browser gespeichert werden können.  
* Stattdessen sollte man in diesem Fall die Methode POST benutzen.
 
====  HTTP POST ====
Da sich die Daten nicht in der URL befinden, können per POST große Datenmengen, zum Beispiel Bilder, übertragen werden.
 
Im folgenden Beispiel wird wieder der Artikel ''Katzen'' angefordert, doch diesmal verwendet der Browser aufgrund eines modifizierten HTML-Codes (method="POST") eine POST-Anfrage.
* Die Variablen stehen dabei nicht in der URL, sondern gesondert im Rumpfteil, etwa:
 
<syntaxhighlight lang="http">
POST /wiki/Spezial:Search HTTP/1.1
Host: de.wikipedia.org
Content-Type: application/x-www-form-urlencoded
Content-Length: 24
 
search=Katzen&go=Artikel
</syntaxhighlight>
 
Auch das versteht der Server und antwortet wieder mit beispielsweise folgendem Text:
<syntaxhighlight lang="http">
HTTP/1.1 302 Found
Date: Fri, 13 Jan 2006 15:32:43 GMT
Location: http://de.wikipedia.org/wiki/Katzen
…
</syntaxhighlight>
 
== HTTP-Statuscodes ==
[[Datei:404 not found.png|mini|Mit Fehler 404 kommen Web-Nutzer am häufigsten in Berührung]]
 
; Jede HTTP-Anfrage wird vom Server mit einem HTTP-Statuscode beantwortet
Er gibt zum Beispiel Informationen darüber, ob die Anfrage erfolgreich bearbeitet wurde, oder teilt dem Client, also etwa dem Browser, im Fehlerfall mit, wo (zum Beispiel Umleitung) beziehungsweise wie (zum Beispiel mit Authentifizierung) er die gewünschten Informationen (wenn möglich) erhalten kann.
 
{| class="wikitable sortable options"
|-
|-
! Option !! Beschreibung
| [https://www.rfc-editor.org/info/rfc7230 RFC 7230] || Message Syntax and Routing
|-
|-
| 1xx – Informationen || Die Bearbeitung der Anfrage dauert trotz der Rückmeldung noch an.
| [https://www.rfc-editor.org/info/rfc7231 RFC 7231] || Semantics and Content
* Eine solche Zwischenantwort ist manchmal notwendig, da viele Clients nach einer bestimmten Zeitspanne ([[Zeitüberschreitung]]) automatisch annehmen, dass ein Fehler bei der Übertragung oder Verarbeitung der Anfrage aufgetreten ist, und mit einer Fehlermeldung abbrechen.
|-
|-
| 2xx – Erfolgreiche Operation ||Die Anfrage wurde bearbeitet und die Antwort wird an den Anfragesteller zurückgesendet.
| [https://www.rfc-editor.org/info/rfc72320 RFC 7232] || Conditional Requests
|-
|-
| 3xx – Umleitung || Um eine erfolgreiche Bearbeitung der Anfrage sicherzustellen, sind weitere Schritte seitens des Clients erforderlich.  
| [https://www.rfc-editor.org/info/rfc7233 RFC 7233] || Range Requests
* Das ist zum Beispiel der Fall, wenn eine Webseite vom Betreiber umgestaltet wurde, so dass sich eine gewünschte Datei nun an einem anderen Platz befindet.
* Mit der Antwort des Servers erfährt der Client im ''Location''-Header, wo sich die Datei jetzt befindet.
|-
|-
| 4xx – [[Client]]-Fehler || Bei der Bearbeitung der Anfrage ist ein Fehler aufgetreten, der im Verantwortungsbereich des Clients liegt.
| [https://www.rfc-editor.org/info/rfc7234 RFC 7234] || Caching
* Ein 404 tritt beispielsweise ein, wenn ein Dokument angefragt wurde, das auf dem Server nicht existiert.
* Ein 403 weist den Client darauf hin, dass es ihm nicht erlaubt ist, das jeweilige Dokument abzurufen.
* Es kann sich zum Beispiel um ein vertrauliches oder nur per [[Hypertext Transfer Protocol Secure|HTTPS]] zugängliches Dokument handeln.
|-
|-
| 5xx – [[Server]]-Fehler || Es ist ein Fehler aufgetreten, dessen Ursache beim Server liegt.
| [https://www.rfc-editor.org/info/rfc7235 RFC 7235] || Authentication
* Zum Beispiel bedeutet 501, dass der Server nicht über die erforderlichen Funktionen (das heißt zum Beispiel Programme oder andere Dateien) verfügt, um die Anfrage zu bearbeiten.
|}
|}


Zusätzlich zum Statuscode enthält der Header der Server-Antwort eine Beschreibung des Fehlers in [[Englische Sprache|englischsprachigem]] Klartext.
===== Weblinks =====
* Zum Beispiel ist ein [[Toter Link|Fehler 404]] an folgendem Header zu erkennen:
# https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol
<syntaxhighlight lang="http">
HTTP/1.1 404 Not Found
…
</syntaxhighlight>
 
siehe auch [[HTTP:Statuscode]]
 
== HTTP-Authentifizierung ==
[[Datei:Http auth iw 10.png|mini|HTTP-Authentifizierung]]
Stellt der Webserver fest, dass für eine angeforderte Datei Benutzername oder Passwort nötig sind, meldet er das dem Browser mit dem Statuscode ''401 Unauthorized'' und dem Header ''WWW-Authenticate''.
* Dieser prüft, ob die Angaben vorliegen, oder präsentiert dem Anwender einen Dialog, in dem Name und Passwort einzutragen sind, und überträgt diese an den Server.
* Stimmen die Daten, wird die entsprechende Seite an den Browser gesendet.
* Es wird nach RFC 2617 unterschieden in:
; Basic Authentication: Die Basic Authentication ist die häufigste Art der HTTP-Authentifizierung.
* Der Webserver fordert eine Authentifizierung an, der Browser sucht daraufhin nach Benutzername/Passwort für diese Datei und fragt gegebenenfalls den Benutzer.
* Anschließend sendet er die Authentifizierung mit dem Authorization-Header in der Form ''Benutzername:Passwort'' [[Base64]]-codiert an den Server.
* Base64 bietet keinen kryptographischen Schutz, daher kann dieses Verfahren nur beim Einsatz von [[Hypertext Transfer Protocol Secure|HTTPS]] als sicher angesehen werden.
; Digest Access Authentication: Bei der Digest Access Authentication sendet der Server zusätzlich mit dem WWW-Authenticate-Header eine eigens erzeugte zufällige Zeichenfolge ([[Nonce]]).
* Der Browser berechnet den [[Hashcode]] der gesamten Daten (Benutzername, Passwort, erhaltener Zeichenfolge, HTTP-Methode und angeforderter [[Uniform Resource Identifier|URI]]) und sendet sie im Authorization-Header zusammen mit dem Benutzernamen und der zufälligen Zeichenfolge zurück an den Server, der diese mit der selbst berechneten Prüfsumme vergleicht.
* Ein Abhören der Kommunikation nützt hier einem Angreifer nichts, da sich aufgrund der verwendeten [[Kryptologische Hashfunktion|kryptologischen Hashfunktion]] aus dem Hashcode die Daten nicht rekonstruieren lassen und für jede Anforderung anders lauten.
 
siehe auch [[HTTP:Authentifizierung]]
 
== HTTP-Kompression ==
Um die übertragene Datenmenge zu verringern, kann ein HTTP-Server seine Antworten [[Datenkompression|komprimieren]].
* Ein Client muss bei einer Anfrage mitteilen, welche Kompressionsverfahren er verarbeiten kann.
* Dazu dient der Header ''Accept-Encoding'' (etwa ''Accept-Encoding: [[gzip]], [[deflate]]'').
* Der Server kann dann die Antwort mit einem vom Client unterstützten Verfahren komprimieren und gibt im Header ''Content-Encoding'' das verwendete Kompressionsverfahren an.
 
HTTP-Kompression spart vor allem bei textuellen Daten (HTML, XHTML, CSS, Javascript-Code, XML, JSON) erhebliche Datenmengen, da sich diese gut komprimieren lassen.
* Bei bereits komprimierten Daten (etwa gängige Formate für Bilder, Audio und Video) ist die (erneute) Kompression nutzlos und wird daher üblicherweise nicht benutzt.
 
In Verbindung mit einer mit [[Transport Layer Security|TLS]] verschlüsselten Kommunikation führt die Komprimierung allerdings zum [[Transport_Layer_Security#Kompressionsangriffe|BREACH]]-[[Exploit]], wodurch die Verschlüsselung gebrochen werden kann.
 
== Applikationen über HTTP ==
HTTP als textbasiertes Protokoll wird nicht nur zur Übertragung von Webseiten verwendet, es kann auch in eigenständigen Applikationen, den [[Webservice]]s, verwendet werden.
* Dabei werden die HTTP-eigenen Befehle wie GET und POST für [[CRUD]]-Operationen weiterverwendet.
* Dies hat den Vorteil, dass kein eigenes Protokoll für die [[Datenübertragung]] entwickelt werden muss.
* Beispielhaft wird dies bei [[Representational State Transfer|REST]] eingesetzt.
 
== HTTP im Vergleich mit dem QUIC-Protokoll ==
HTTP stützt sich auf das [[Transmission Control Protocol]] (TCP).
* TCP bestätigt den Erhalt jedes Datenpakets.
* Dies führt dazu, dass im Falle eines Paketverlustes alle anderen Pakete auf die erneute Übertragung des verloren gegangenen warten müssen, wenn der Empfängercache überläuft (''Head-of-Line Blocking''<ref>{{Internetquelle |url=https://www.ionos.de/digitalguide/hosting/hosting-technik/was-ist-http/ |titel=Was ist HTTP? |abruf=2021-03-25 |sprache=de}}</ref>)
 
Das [[Quick UDP Internet Connections|QUIC-Protokoll]] soll in seiner Gesamtheit ein schnelleres Versenden von Datenpaketen über das verbindungslose [[User Datagram Protocol|UDP]] ermöglichen.
* Funktionen, die UDP fehlen – wie beispielsweise Empfangsbestätigungen – müssen vom übergeordneten Protokoll bereitgestellt werden.
* QUIC regelt die Verbindungskontrolle selbst.
* Sender und Empfänger tauschen bei einer Datenverbindung lediglich beim ersten Handshake das Zertifikat und den Schlüssel aus, wodurch sich die Latenz verringert.
* Bei weiteren Sendevorgängen „erinnert“ sich QUIC an die in der Vergangenheit bestehende Verbindung und greift auf die gespeicherten Daten zu.
* Als Verschlüsselungsprotokoll wird aktuell die [[Transport Layer Security|TLS]] Version 1.3 verwendet.
* Im QUIC-Protokoll besteht außerdem die Möglichkeit des ''[[Multiplexverfahren|Multiplexing]]''.
* Dabei können über eine Client-Server-Verbindung mehrere Datenströme gleichzeitig übertragen werden, was die Ladezeit nochmals deutlich reduziert.<ref>{{Internetquelle |url=https://www.ionos.de/digitalguide/hosting/hosting-technik/quic-das-internet-transportprotokoll-auf-udp-basis/ |titel=QUIC: Das steckt hinter dem experimentellen Google-Protokoll |abruf=2021-03-25 |sprache=de}}</ref>
 
== Anwendungen ==
=== Fehlerbehebung ===
 
== Syntax ==
=== Optionen ===
=== Parameter ===
=== Umgebungsvariablen ===
=== Exit-Status ===
== Konfiguration ==
=== Dateien ===
== Sicherheit ==
== Dokumentation ==
=== RFC ===
=== Man-Pages ===
=== Info-Pages ===
== Siehe auch ==
* [[Liste der HTTP-Headerfelder]]
* [[Request Cycle]]
* [[SOAP]]
* [[Extensible Markup Language]] (XML)
* [[Zeichenkodierung]]
* [[Content Negotiation]]
* [[HTTP ETag]]
* [[HTTP Caching]]
 
== Links ==
=== Projekt-Homepage ===
 
=== Weblinks ===
# https://developer.mozilla.org/de/docs/Web/HTTP/Status/504
# Wikiversity|Kurs:Internet und Verschluesselung/World Wide Web/HTTP
# [https://tools.ietf.org/wg/httpbis/ Arbeitsgruppe der IETF zur Weiterentwicklung von HTTP]
# [http://httptea.sourceforge.net/ ''HttpTea'', ein HTTP-Analysator] (Freeware, englisch)
# dmoz|World/Deutsch/Computer/Netzwerk/Protokolle_und_Dienste/HTTP/|HTTP
# [https://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility-01 Microsofts ausführlicher Bericht zu http 2.0] (englisch)
 
=== Einzelnachweise ===
<references>
<ref name="HTTP0.9">
Tim Berners-Lee: [http://www.w3.org/Protocols/HTTP/AsImplemented.html ''The Original HTTP as defined in 1991''.] In: ''w3.org'', abgerufen am 13. November 2010.
</ref>
<ref name="RFC2616">
RFC 2616 ''Hypertext Transfer Protocol – HTTP/1.1''
</ref>
<!-- ZUR ZEIT NICHT VERWENDET:
<ref name="HTTP2-draft14">
[https://tools.ietf.org/html/draft-ietf-httpbis-http2-14 14. Entwurf für Version 2 des Hypertext Transfer Protocol] HTTP-Arbeitsgruppe, 30. Juli 2014; abgerufen 3. Oktober 2014
</ref>
<ref name="HTTP2-draft8">
[http://tools.ietf.org/html/draft-ietf-httpbis-http2-08 HTTP/2 8. Entwurf für Version 2 des Hypertext Transfer Protocol] HTTP-Arbeitsgruppe, 11. November 2013; abgerufen 13. November 2013
</ref>
<ref name="Golem.2012-01-24">
Jens Ihlenfeld: [http://www.golem.de/1201/89265.html Mit SPDY auf dem Weg zu HTTP/2.0?] Golem.de; 24. Januar 2012
</ref>
-->
<ref name="heise.2012-03-29">
{{Internetquelle
|url=http://heise.de/-1479694.html
|titel=Microsoft bringt eigenen Vorschlag für HTTP 2
|autor=Christian Kirsch
|hrsg=heise.de
|datum=2012-03-29
|abruf=2012-04-04}}
</ref>
<ref name="heise.2009-11-13">
Christian Kirsch: [http://heise.de/-858994.html ''Googles SPDY soll das Web beschleunigen''.] heise.de, 13. November 2009; abgerufen am 4. April 2012
</ref>
<ref name="HPACK">
[https://http2.github.io/http2-spec/compression.html Entwurf der Spezifikation von HPACK] (dem Header-Kompressionsalgorithmus für HTTP/2). HTTP-Arbeitsgruppe der IETF
</ref>
<ref name="HTML 4.01-B.2.2">
{{Literatur
|Hrsg=World Wide Web Consortium [W3C]
|Titel=Appendix B: Performance, Implementation, and Design Notes
|Sammelwerk=HTML 4.01 Specification
|Datum=1999-12-24
|Kapitel=B.2.2: Ampersands in URI attribute values
|Online=[http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.2.2 w3.org]}}
</ref>
</references>
<references />
 
== Testfragen ==
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 1''
<div class="mw-collapsible-content">'''Antwort1'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 2''
<div class="mw-collapsible-content">'''Antwort2'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 3''
<div class="mw-collapsible-content">'''Antwort3'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 4''
<div class="mw-collapsible-content">'''Antwort4'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 5''
<div class="mw-collapsible-content">'''Antwort5'''</div>
</div>
 
[[Kategorie:Entwurf]]


= Wikipedia =
<noinclude>
| Logo = [[Datei:HTTP logo.svg|200px|HTTP-Logo der HTTP-Arbeitsgruppe der IETF]]
| Familie = [[Internetprotokollfamilie]]
| Einsatzfeld = Datenübertragung (Hypertext u.&nbsp;a.) auf Anwendungsschicht
| aufbauend auf = [[Transmission Control Protocol|TCP]] (Transport für HTTP/1.1 und /2)[[QUIC]] (Transport für HTTP/3)
| Basis zu =
| Einführung = 1991
| entwickelt aus =
| entwickelt zu =
| Version = 3
| Version Datum = 2022
| Standard = RFC 1945 HTTP/1.0 (1996)
RFC 2616 HTTP/1.1 (1999)
RFC 9113 HTTP/2 (2022)
RFC 9114 HTTP/3 (2022)
RFC 7541 Header Compression (2, 2015)
RFC 7230 Message Syntax and Routing (1.1, 2014)
RFC 7231 Semantics and Content (1.1, 2014)
RFC 7232 Conditional Requests (1.1, 2014)
RFC 7233 Range Requests (1.1, 2014)
RFC 7234 Caching (1.1, 2014)
RFC 7235 Authentication (1.1, 2014)


[[Kategorie:HTTP]]
[[Kategorie:HTTP]]
[[Kategorie:Netzwerke:Web:Protokolle]]
</noinclude>

Aktuelle Version vom 27. Juli 2024, 10:36 Uhr

Hypertext Transfer Protocol (HTTP) - Protokoll zur Übertragung von Daten auf der Anwendungsschicht

Beschreibung

Hypertext-Übertragungsprotokoll
Webseiten
  • Es wird hauptsächlich eingesetzt, um Webseiten (Hypertext-Dokumente) aus dem World Wide Web (WWW) in einen Webbrowser zu laden
  • Es ist jedoch nicht prinzipiell darauf beschränkt und auch als allgemeines Dateiübertragungsprotokoll sehr verbreitet
Standardisierung
HTTP wurde von der Internet Engineering Task Force (IETF) und dem World Wide Web Consortium (W3C) standardisiert
  • Aktuelle Version ist HTTP/3, welche als RFC 9114 im Juni 2022 veröffentlicht wurde
  • Die Weiterentwicklung wird von der HTTP-Arbeitsgruppe der IETF (HTTPbis) organisiert
Ergänzende und aufbauende Standards
  • HTTPS für die Kryptografie übertragener Inhalte
  • WebDAV Übertragungsprotokoll

Eigenschaften

Nach etablierten Schichtenmodellen zur Einordnung von Netzwerkprotokollen nach ihren grundlegenderen oder abstrakteren Aufgaben wird HTTP der sogenannten Anwendungsschicht zugeordnet

Zustandslos

HTTP ist ein zustandsloses Protokoll

  • Informationen aus früheren Anforderungen gehen verloren
  • Ein zuverlässiges Mitführen von Sitzungsdaten kann erst auf der Anwendungsschicht durch eine Sitzung über einen Sitzungsbezeichner implementiert werden

Cookies

Über Cookies in den Header-Informationen können aber Anwendungen realisiert werden, die Statusinformationen (Benutzereinträge, Warenkörbe) zuordnen können

Methoden

Durch Erweiterung seiner Anfragemethoden, Header-Informationen und Statuscodes ist HTTP nicht auf Hypertext beschränkt, sondern wird zunehmend zum Austausch beliebiger Daten verwendet, außerdem ist es Grundlage des auf Dateiübertragung spezialisierten Protokolls WebDAV

Derzeit werden hauptsächlich zwei Protokollversionen, HTTP/1.0 und HTTP/1.1, verwendet

Aufbau

Die Kommunikationseinheiten in HTTP zwischen Client und Server werden als Nachrichten bezeichnet, von denen es zwei unterschiedliche Arten gibt: die Anfrage (englisch Request) vom Client an den Server und die Antwort (englisch Response) als Reaktion darauf vom Server zum Client

Jede Nachricht besteht dabei aus zwei Teilen

Option Beschreibung
Nachrichtenkopf Message Header, Header, HTTP-Header Informationen über den Nachrichtenrumpf, damit dieser vom Empfänger korrekt interpretiert werden kann
Nachrichtenrumpf Message Body, Body Nutzdaten

Funktion

Transaktion mit Telnet

Wenn in einem Web Browser der Link zur URL http://www.example.net/infotext.html aktiviert wird, so wird an den Rechner mit dem Hostnamen www.example.net die Anfrage gerichtet, die Ressource /infotext.html zurückzusenden

Der Name www.example.net wird dabei zuerst über das DNS-Protokoll in eine IP-Adresse umgesetzt

  • Zur Übertragung wird über TCP auf den Standard-Port 80 des HTTP-Servers eine HTTP-GET-Anforderung gesendet

Anfrage

GET /infotext.html HTTP/1.1
Host: www.example.net

Enthält der Link Zeichen, die in der Anfrage nicht erlaubt sind, werden diese %-kodiert

  • Zusätzliche Informationen wie Angaben über den Browser, zur gewünschten Sprache etc
  • können über den Header (Kopfzeilen) in jeder HTTP-Kommunikation übertragen werden
  • Mit dem „Host“-Feld lassen sich verschiedene DNS-Namen unter der gleichen IP-Adresse unterscheiden
  • Unter HTTP/1.0 ist es optional, unter HTTP/1.1 jedoch erforderlich
  • Sobald der Header mit einer Leerzeile (beziehungsweise zwei aufeinanderfolgenden Zeilenenden) abgeschlossen wird, sendet der Rechner, der einen Web-Server (an Port 80) betreibt, seinerseits eine HTTP-Antwort zurück
  • Diese besteht aus den Header-Informationen des Servers, einer Leerzeile und dem tatsächlichen Inhalt der Nachricht, also dem Dateiinhalt der infotext.html-Datei. Übertragen werden Dateien normalerweise in Seitenbeschreibungssprachen wie (X)HTML und alle ihre Ergänzungen, zum Beispiel Bilder, Stylesheets (CSS), Skripte (JavaScript) usw., die meistens von einem Browser in einer lesbaren Darstellung miteinander verbunden werden
  • Prinzipiell kann jede Datei in jedem beliebigen Format übertragen werden, wobei die „Datei“ auch dynamisch generiert werden kann und nicht auf dem Server als physische Datei vorhanden zu sein braucht (zum Beispiel bei Anwendung von CGI, SSI, JSP, PHP oder ASP.NET)

Jede Zeile im Header wird durch den Zeilenumbruch <CR><LF> abgeschlossen

  • Die Leerzeile nach dem Header darf nur aus <CR><LF>, ohne eingeschlossenes Leerzeichen, bestehen

Antwort

HTTP/1.1 200 OK
Server: Apache/1.3.29 (Unix) PHP/4.3.4
Content-Length: 123456 (Größe von infotext.html in Byte)
Content-Language: de (nach RFC 3282 sowie RFC 1766)
Connection: close
Content-Type: text/html
(Inhalt von infotext.html)
Status

Der Server sendet eine Fehlermeldung sowie einen Fehlercode zurück, wenn die Information aus einem Grund nicht gesendet werden kann, allerdings werden auch dann Statuscodes verwendet, wenn die Anfrage erfolgreich war, in dem Falle (meistens) 200 OK

  • Der genaue Ablauf dieses Vorgangs (Anfrage und Antwort) ist in der HTTP-Spezifikation festgelegt
Methoden
Statuscode
Authentifizierung
Kompression

Versionen

Version Beschreibung
HTTP/0.9
HTTP/1.0
HTTP/1.1
HTTP/2
HTTP/3

HTTP/0.9

Sir Tim Berners-Lee gilt als Begründer des Webs und entwickelte auch HTTP mit

Ab 1989 entwickelten Tim Berners-Lee und sein Team am CERN, dem europäischen Kernforschungszentrum in der Schweiz, das Hypertext Transfer Protocol, zusammen mit den Konzepten URL und HTML, womit die Grundlagen des World Wide Web geschaffen wurden. Erste Ergebnisse dieser Bemühungen war 1991 die Version HTTP 0.9

HTTP/1.0

Die im Mai 1996 als RFC 1945 (Request for Comments Nr. 1945) publizierte Anforderung ist als HTTP/1.0 bekannt geworden Bei HTTP/1.0 wird vor jeder Anfrage eine neue TCP-Verbindung aufgebaut und nach Übertragung der Antwort standardmäßig vom Server 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

HTTP/1.1

1999 wurde eine zweite Anforderung als RFC 2616 publiziert, die den HTTP/1.1-Standard wiedergibt Bei HTTP/1.1 kann ein Client durch einen zusätzlichen Headereintrag (Keepalive) den Wunsch äußern, keinen Verbindungsabbau durchzuführen, um die Verbindung erneut nutzen zu können (persistent connection)

  • Die Unterstützung auf Serverseite ist jedoch optional und kann in Verbindung mit Proxys Probleme bereiten
  • Mittels HTTP-Pipelining können in der Version 1.1 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 durch Verwendung 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

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

Mit HTTP/1.1 ist es neben dem Abholen von Daten auch möglich, Daten zum Server zu übertragen

  • Mit Hilfe 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 der Weg zum Webserver verfolgt und überprüft werden kann, ob die Daten korrekt dorthin übertragen werden
  • Damit ergibt sich die Möglichkeit, den Weg zum Webserver über die verschiedenen Proxys hinweg zu ermitteln, ein traceroute auf Anwendungsebene

Aufgrund von Unstimmigkeiten und Unklarheiten wurde 2007 eine Arbeitsgruppe gestartet, die die Spezifikation verbessern sollte

  • Ziel war hier lediglich eine klarere Formulierung, neue Funktionen wurden nicht eingebaut
Dieser Prozess wurde 2014 beendet und führte zu sechs RFCs
  • RFC 7230 – HTTP/1.1: Message Syntax and Routing
  • RFC 7231 – HTTP/1.1: Semantics and Content
  • RFC 7232 – HTTP/1.1: Conditional Requests
  • RFC 7233 – HTTP/1.1: Range Requests
  • RFC 7234 – HTTP/1.1: Caching
  • RFC 7235 – HTTP/1.1: Authentication

HTTP/2

Im Mai 2015 wurde von der IETF HTTP/2 als Nachfolger von HTTP/1.1 verabschiedet

  • Der Standard ist durch RFC 7540 und RFC 7541 spezifiziert. Die Entwicklung war maßgeblich von Google (SPDY) und Microsoft (HTTP Speed+Mobility) mit jeweils eigenen Vorschlägen vorangetrieben worden
  • Ein erster Entwurf, der sich weitgehend an SPDY anlehnte, war im November 2012 publiziert und seither in mehreren Schritten angepasst worden

Mit HTTP/2 soll die Übertragung beschleunigt und optimiert werden. Dabei soll der neue Standard jedoch vollständig abwärtskompatibel zu HTTP/1.1 sein

Wichtige neue Möglichkeiten sind
  • die Möglichkeit des Zusammenfassens mehrerer Anfragen
  • weitergehende Datenkompressionsmöglichkeiten
  • die binär kodierte Übertragung von Inhalten und
  • Server-initiierte Datenübertragungen (push-Verfahren)
  • einzelne Streams können priorisiert werden
Beschleunigung

Eine Beschleunigung ergibt sich hauptsächlich aus der neuen Möglichkeit des Zusammenfassens (Multiplex) mehrerer Anfragen, um sie über eine Verbindung abwickeln zu können

  • Die Datenkompression kann nun (mittels neuem Spezialalgorithmus namens HPACK) auch Kopfdaten einschließen
  • Inhalte können binär kodiert übertragen werden
  • Um nicht auf serverseitig vorhersehbare Folgeanforderungen vom Client warten zu müssen, können Datenübertragungen teilweise vom Server initiiert werden (push-Verfahren)
  • Durch die Verwendung von HTTP/2 können Webseitenbetreiber die Latenz zwischen Client und Server verringern und die Netzwerkhardware entlasten

Die ursprünglich geplante Option, dass HTTP/2 standardmäßig TLS nutzt, wurde nicht umgesetzt

  • Allerdings kündigten die Browser-Hersteller Google und Mozilla an, dass ihre Webbrowser nur verschlüsselte HTTP/2-Verbindungen unterstützen werden
  • Dafür ist ALPN eine Kryptografie-Erweiterung, die TLSv1.2 oder neuer benötigt
Unterstütztung

HTTP/2 wird von den meisten Browsern unterstützt, darunter Google Chrome (inkl. Chrome unter iOS und Android) ab Version 41, Mozilla Firefox ab Version 36, Internet Explorer 11 unter Windows 10, Opera ab Version 28 (sowie Opera Mobile ab Version 24) und Safari ab Version 8

HTTP/3

QUIC setzt nicht mehr auf das verbindungsorientierte TCP, sondern auf das verbindungslose User Datagram Protocol (UDP)

  • Auch bei dem darauf aufbauenden HTTP/3 werden Datenströme getrennt verarbeitet
  • Geht ein Paket unterwegs verloren, betrifft es nicht mehr alle Datenströme, wie es bei TCP der Fall ist
  • Bei HTTP/3 wird der betroffene Strom warten, bis das fehlende Paket eintrifft
  • HTTP/3 ist generell verschlüsselt und verspricht deutliche Geschwindigkeitsvorteile
Entwicklung

Im Juni 2022 wurde HTTP/3 als RFC 9114 standardisiert

  • Im November 2018 wurde von der IETF beschlossen, dass HTTP/3 QUIC verwenden solle
  • Google arbeitet schon seit 2012 an einer Alternative unter dem Namen QUIC

Google Chrome Canary war ab Mitte 2019 der erste verfügbare Browser, der eine experimentelle #QUIC- und HTTP/3-Unterstützung integriert hatte. cURL zog bald nach

  • Die Vorab-Versionen von Firefox (nightly und beta) versuchen seit April 2021 automatisch, HTTP/3 zu verwenden, wenn es vom Webserver (derzeit z.B Google oder Facebook) angeboten wird
  • Webserver können die Unterstützung anzeigen, indem sie den Alt-Svc-Antwortheader verwenden oder die HTTP/3-Unterstützung mit einem HTTPS-DNS-Eintrag ankündigen
  • Sowohl der Client als auch der Server müssen dieselbe QUIC- und HTTP/3-Entwurfsversion unterstützen, um sich verbinden zu können
  • Firefox unterstützt beispielsweise derzeit die Entwürfe 27 bis 32 der Spezifikation, sodass der Server die Unterstützung einer dieser Versionen (z. B. „h3-32“) im Alt-Svc- oder HTTPS-Eintrag melden muss, damit Firefox versucht, QUIC und HTTP/3 mit diesem Server zu verwenden
  • Beim Besuch einer solchen Website sollte in den Netzwerkanforderungsinformationen darauf hingewiesen werden, dass HTTP/3 verwendet wird

Anhang

Siehe auch

Dokumentation

RFC Titel
RFC 2616 HTTP/1.1
RFC 9113 HTTP/2
RFC 9114 HTTP/3
RFC 7541 Header Compression
RFC 7230 Message Syntax and Routing
RFC 7231 Semantics and Content
RFC 7232 Conditional Requests
RFC 7233 Range Requests
RFC 7234 Caching
RFC 7235 Authentication
Weblinks
  1. https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol
Abgerufen von „https://wiki.foxtom.de/index.php?title=Hypertext_Transfer_Protocol&oldid=103967“