HTTP

HTTP ( Hypertext Transfer Protocol ) ist ein Anwendungsschichtprotokoll aus der Internetprotokollfamilie für verteilte, kollaborative Hypermedia- Informationssysteme. ^{[ 1 ]} HTTP bildet die Grundlage der Datenkommunikation im World Wide Web , wo Hypertext- Dokumente Hyperlinks zu anderen Ressourcen enthalten, auf die der Benutzer beispielsweise per Mausklick oder durch Tippen auf den Bildschirm in einem Webbrowser einfach zugreifen kann .

HTTP ist ein Anfrage-Antwort- Protokoll im Client-Server-Modell . Eine Transaktion beginnt damit, dass ein Client eine Anfrage an den Server sendet. Der Server versucht, die Anfrage zu bearbeiten und sendet eine Antwort an den Client zurück, die den Status der Anfrage beschreibt und optional eine angeforderte Ressource wie ein HTML- Dokument oder andere Inhalte enthält.

In einem typischen Szenario fungiert ein Webbrowser als Client und ein Webserver , der eine oder mehrere Websites hostet , als Server . Ein Webbrowser ist ein Beispiel für einen User-Agent (UA). Weitere Arten von User-Agents sind die von Suchmaschinenanbietern verwendete Indexierungssoftware ( Webcrawler ), Sprachbrowser , mobile Apps und andere Software , die auf Webinhalte zugreift, diese verarbeitet oder anzeigt.

HTTP ist so konzipiert, dass zwischengeschaltete Netzwerkkomponenten die Kommunikation zwischen Clients und Servern verbessern oder ermöglichen. Websites mit hohem Traffic profitieren oft von Web-Cache -Servern, die Inhalte im Auftrag von Upstream-Servern ausliefern , um die Antwortzeiten zu verkürzen. Webbrowser speichern zuvor aufgerufene Webressourcen im Cache und verwenden sie nach Möglichkeit wieder, um den Netzwerkverkehr zu reduzieren. HTTP- Proxy-Server an den Grenzen privater Netzwerke können die Kommunikation für Clients ohne global erreichbare IP-Adresse erleichtern, indem sie Nachrichten an externe Server weiterleiten.

Damit zwischengeschaltete HTTP-Knoten (Proxy-Server, Web-Caches usw.) ihre Funktionen erfüllen können, werden einige der HTTP-Header (die in HTTP-Anfragen/Antworten zu finden sind) Hop-by-Hop verwaltet , während andere HTTP-Header End-to-End verwaltet werden (nur vom Quellclient und vom Zielwebserver verwaltet).

Eine Webressource wird über einen Uniform Resource Locator (URL) mithilfe der Uniform Resource Identifier (URI)-Schemata http und https lokalisiert . URIs werden in HTML- Dokumenten als Hyperlinks kodiert , um miteinander verknüpfte Hypertext- Dokumente zu bilden. ^{[ 2 ]}

Das Protokoll wurde im Laufe der Zeit überarbeitet. Eine Version wird als HTTP/# gekennzeichnet, wobei # die Versionsnummer ist. Dieser Artikel behandelt Aspekte aller Versionen, konzentriert sich aber hauptsächlich auf HTTP/0.9, HTTP/1.0 und HTTP/1.1. HTTP/2 und HTTP/3 werden in separaten Artikeln detailliert beschrieben.

Bei HTTP/1.0 wird für jede Ressourcenanforderung eine separate TCP- Verbindung zum selben Server hergestellt. ^{[ 3 ] : §1.3}

Bei HTTP/1.1 kann eine TCP-Verbindung hingegen für mehrere Ressourcenanforderungen (z. B. von HTML-Seiten, Frames, Bildern, Skripten , Stylesheets usw.) wiederverwendet werden. ^{[ 4 ] : §9.1,9.3} Die Kommunikation über HTTP/1.1 weist daher eine geringere Latenz auf , da der Aufbau von TCP-Verbindungen einen erheblichen Aufwand verursacht, insbesondere bei hohem Datenverkehr. ^{[ 5 ]}

Die mit HTTP/2 eingeführten Verbesserungen ermöglichen geringere Latenzzeiten und in den meisten Fällen höhere Übertragungsgeschwindigkeiten als HTTP/1.1. HTTP/2 bietet Unterstützung für:

• eine komprimierte Binärdarstellung der Metadaten (HTTP-Header) anstelle einer textuellen Darstellung, sodass die Header viel weniger Speicherplatz benötigen;
• eine einzige TCP/IP -Verbindung (in der Regel verschlüsselt ) pro aufgerufener Serverdomäne anstelle von 2 bis 8 TCP/IP-Verbindungen;
• ein oder mehrere bidirektionale Datenströme pro TCP/IP-Verbindung, in denen HTTP-Anfragen und -Antworten in kleine Pakete aufgeteilt und übertragen werden, um das HOLB-Problem ( Head-of-Line-Blocking ) nahezu zu lösen; ^{[ Anmerkung 1 ]}
• Eine Push-Funktion, die es der Serveranwendung ermöglicht, Daten an Clients zu senden, sobald neue Daten verfügbar sind (ohne dass Clients gezwungen sind, regelmäßig neue Daten vom Server mittels Polling- Methoden anzufordern ). ^{[ 6 ] : §2}

HTTP/3 verwendet die Transportprotokolle QUIC und UDP anstelle von TCP. Es wird ausschließlich die IP-Schicht genutzt (auf der UDP, wie TCP, aufbaut). Dies verbessert die durchschnittliche Übertragungsgeschwindigkeit leicht und vermeidet das gelegentliche Problem der TCP- Verbindungsüberlastung , die den Datenfluss aller Datenströme vorübergehend blockieren oder verlangsamen kann (eine Form der „ Head-of-Line-Blocking “).

HTTP/2 wird von 71 % der Websites unterstützt ^{[ 7 ] [ 8 ]} (34,1 % HTTP/2 + 36,9 % HTTP/3 mit Abwärtskompatibilität) und von nahezu allen Webbrowsern (über 98 % der Nutzer) unterstützt. ^{[ 9 ]} Es wird außerdem von den meisten Webservern über Transport Layer Security (TLS) mithilfe der Application-Layer Protocol Negotiation (ALPN)-Erweiterung unterstützt ^{[ 10 ]} , wobei TLS 1.2 oder höher erforderlich ist. ^{[ 6 ]}

HTTP/3 wird auf 36,9 % aller Websites verwendet ^{[ 11 ]} und von den meisten Webbrowsern unterstützt, d. h. (zumindest teilweise) von 97 % der Nutzer. ^{[ 12 ]} HTTP/3 verwendet QUIC anstelle von TCP als zugrundeliegendes Transportprotokoll. Wie HTTP/2 ersetzt es keine früheren Hauptversionen des Protokolls. 2019 wurde die Unterstützung für HTTP/3 erstmals in Cloudflare und Chrome ^{[ 13 ] [ 14 ]} eingeführt und auch in Firefox aktiviert . ^{[ 15 ]} HTTP/3 bietet eine geringere Latenz für Webseiten in der Praxis und lädt schneller als HTTP/2, in manchen Fällen mehr als dreimal schneller als HTTP/1.1, das immer noch häufig das einzige aktivierte Protokoll ist. ^{[ 16 ]}

HTTPS , die sichere Variante von HTTP, wird von mehr als 85 % der Websites verwendet. ^{[ 17 ]}

HTTP setzt ein zugrundeliegendes und zuverlässiges Transportprotokoll voraus . ^{[ 18 ] : §3.3} Vor HTTP/3 war das Transmission Control Protocol (TCP) der Standard für das zugrundeliegende Protokoll. HTTP/3 verwendet eine andere Transportschicht namens QUIC , die zusätzlich zum unzuverlässigen User Datagram Protocol (UDP) für Zuverlässigkeit sorgt. HTTP/1.1 und frühere Versionen wurden für die Verwendung über das unzuverlässige UDP in Multicast- und Unicast- Situationen angepasst und bilden so HTTPMU und HTTPU. Sie werden in UPnP und dem Simple Service Discovery Protocol (SSDP) verwendet, zwei Protokollen, die üblicherweise in lokalen Netzwerken (LANs) zum Einsatz kommen .

HTTP ist ein zustandsloses Anwendungsprotokoll und benötigt eine zuverlässige Netzwerkverbindung für den Datenaustausch zwischen Client und Server. ^{[ 19 ]} In HTTP-Implementierungen werden TCP/IP -Verbindungen über bekannte Ports verwendet (typischerweise Port 80 bei unverschlüsselter oder Port 443 bei verschlüsselter Verbindung; siehe auch Liste der TCP- und UDP-Portnummern ). ^{[ 18 ] §4.2.1,4.2.2} In HTTP/2 wird eine TCP/IP-Verbindung mit mehreren Protokollkanälen verwendet. In HTTP/3 kommt das Anwendungsprotokoll QUIC über UDP zum Einsatz.

Der Datenaustausch erfolgt über eine Folge von Anfrage-Antwort-Nachrichten , die über eine Sitzungsschichtverbindung ausgetauscht werden . ^{[ 19 ]} Ein HTTP-Client versucht zunächst, eine Verbindung (real oder virtuell) zu einem Server herzustellen. Ein HTTP-Server, der auf dem entsprechenden Port lauscht, akzeptiert die Verbindung und wartet anschließend auf die Anfrage des Clients. Der Client sendet seine HTTP-Anfrage. Nach Erhalt der Anfrage sendet der Server eine HTTP-Antwort, die Header und gegebenenfalls einen Body enthält. Der Body dieser Antwort enthält typischerweise die angeforderte Ressource; es können jedoch auch Fehlermeldungen oder andere Informationen zurückgegeben werden. Client oder Server können die Verbindung jederzeit und aus verschiedenen Gründen schließen. Das Schließen einer Verbindung wird üblicherweise durch einen oder mehrere HTTP-Header in der letzten Anfrage oder Antwort signalisiert. ^{[ 4 ] : §9.1}

Bei HTTP/0.9 wird die TCP/IP-Verbindung immer geschlossen, nachdem die Serverantwort gesendet wurde, sie ist also niemals persistent.

Bei HTTP/1.0 sollte die TCP/IP-Verbindung vom Server immer geschlossen werden, nachdem eine Antwort gesendet wurde. ^{[ 3 ] [ Anmerkung 2 ]}

In HTTP/1.1 wurde offiziell ein Keep-Alive-Mechanismus eingeführt, der die Wiederverwendung einer Verbindung für mehrere Anfragen und Antworten ermöglicht. Solche persistenten Verbindungen reduzieren die Latenz spürbar, da der Client die TCP-Drei-Wege-Handshake-Verbindung nach dem Senden der ersten Anfrage nicht erneut aushandeln muss . Ein weiterer positiver Nebeneffekt ist, dass die Verbindung dank des Slow-Start -Mechanismus von TCP im Allgemeinen mit der Zeit schneller wird .

HTTP/1.1 führte HTTP-Pipelining ein , um die Latenzzeit bei persistenten Verbindungen weiter zu reduzieren. Clients konnten dadurch mehrere Anfragen senden, bevor sie auf die jeweilige Antwort warten mussten. Diese Optimierung galt jedoch nie als wirklich sicher, da einige Webserver und viele Proxyserver , insbesondere transparente Proxyserver im Internet/ Intranet zwischen Clients und Servern, Pipeline-Anfragen nicht korrekt verarbeiteten (sie bearbeiteten nur die erste Anfrage und verwarfen die anderen, schlossen die Verbindung, weil sie nach der ersten Anfrage weitere Daten empfingen, oder einige Proxys lieferten sogar Antworten in falscher Reihenfolge usw.). Aus diesem Grund konnten nur HEAD- und einige GET-Anfragen (d. h. beschränkt auf echte Dateianfragen und somit URLs ohne als Befehl verwendete Query-String usw.) sicher und idempotent per Pipelining verarbeitet werden . Nach jahrelangen Schwierigkeiten mit den durch das Pipelining verursachten Problemen wurde diese Funktion zunächst deaktiviert und dann aus den meisten Browsern entfernt. Auch die Einführung von HTTP/2 führte zur Abschaffung des Pipelinings.

HTTP/2 erweiterte die Nutzung persistenter Verbindungen, indem es viele gleichzeitige Anfragen/Antworten über eine einzige TCP/IP-Verbindung multiplexierte.

HTTP/3 verwendet keine TCP/IP-Verbindungen, sondern QUIC + UDP.

In HTTP/0.9 wurde eine angeforderte Ressource immer vollständig gesendet.

HTTP/1.0 fügte Header hinzu, um vom Client zwischengespeicherte Ressourcen zu verwalten und so bedingte GET-Anfragen zu ermöglichen.

• Ein Server muss den gesamten Inhalt der angeforderten Ressource nur dann zurückgeben, wenn dem Client der Zeitpunkt der letzten Änderung nicht bekannt ist oder wenn sich der Inhalt seit der letzten vollständigen Antwort auf eine GET-Anfrage geändert hat.

• Es wurde ein Header Content-Encodinghinzugefügt, um anzugeben, ob der zurückgegebene Inhalt komprimiert ist .

• Wenn die Größe des Inhalts nicht im Voraus bekannt ist (z. B. weil er dynamisch generiert wird), Content-Lengthwird der Header nicht gesendet. Der Client würde annehmen, dass die Übertragung abgeschlossen ist, sobald die Verbindung geschlossen wird. Ein vorzeitiger Verbindungsabbruch würde jedoch dazu führen, dass der Client nur einen Teil des Inhalts erhält, ohne dies zu bemerken.

HTTP/1.1 wurde eingeführt und spätere Versionen bieten Folgendes:

• Header zur besseren Verwaltung des bedingten Abrufs zwischengespeicherter Ressourcen.

• Die Chunked Transfer Encoding ermöglicht es, Inhalte in Blöcken zu streamen, um sie auch dann zuverlässig zu senden, wenn der Server ihre Länge nicht im Voraus kennt (z. B. weil sie dynamisch generiert werden usw.).

• Die Byte-Bereichsbereitstellung ermöglicht es einem Client, Teile (Byte-Bereiche) einer Ressource anzufordern. Dies ist nützlich, um einen unterbrochenen Download fortzusetzen (bei sehr großen Dateien), wenn nur ein Teil des Inhalts angezeigt oder dynamisch zum bereits sichtbaren Teil hinzugefügt werden soll (z. B. nur der erste oder die folgenden n Kommentare einer Webseite), um Zeit, Bandbreite und Systemressourcen zu sparen.

Als zustandsloses Protokoll erfordert HTTP nicht, dass der Webserver Informationen oder den Status einzelner Benutzer über mehrere Anfragen hinweg speichert. Benötigt eine Webanwendung eine Sitzung , implementiert sie diese über HTTP-Cookies ^{[ 21 ]} , versteckte Variablen in einem Webformular oder einen anderen Mechanismus.

Üblicherweise wird zum Starten einer Sitzung eine interaktive Anmeldung durchgeführt und zum Beenden eine Abmeldung vom Benutzer angefordert. Diese Vorgänge verwenden einen benutzerdefinierten Authentifizierungsmechanismus , nicht die HTTP-Authentifizierung .

HTTP bietet verschiedene Authentifizierungsmethoden wie die Basisauthentifizierung und die Digest-Authentifizierung , die über einen Challenge-Response-Mechanismus funktionieren. Dabei identifiziert der Server den Benutzer und stellt eine Herausforderung, bevor er die angeforderten Inhalte ausliefert.

HTTP bietet ein allgemeines Framework für Zugriffskontrolle und Authentifizierung mittels einer erweiterbaren Menge von Challenge-Response-Authentifizierungsschemata, die von einem Server zur Überprüfung einer Clientanfrage und von einem Client zur Bereitstellung von Authentifizierungsinformationen verwendet werden können. ^{[ 18 ]}

Die oben beschriebenen Authentifizierungsmechanismen gehören zum HTTP-Protokoll und werden von Client- und Server-HTTP-Software verwaltet (sofern diese so konfiguriert ist, dass vor dem Zugriff des Clients auf eine oder mehrere Webressourcen eine Authentifizierung erforderlich ist), und nicht von den Webanwendungen, die eine Anwendungssitzung verwenden .

Die HTTP-Authentifizierungsspezifikation beinhaltet Realms, die eine beliebige, implementierungsspezifische Struktur zur weiteren Unterteilung von Ressourcen bereitstellen, die einem gegebenen Root- URI gemeinsam sind. Der Realm-Wertstring wird, sofern vorhanden, mit dem kanonischen Root-URI kombiniert, um die Schutzbereichskomponente der Herausforderung zu bilden. Dies ermöglicht es dem Server, separate Authentifizierungsbereiche unter einem Root-URI zu definieren. ^{[ 1 ]}

The most popular way of establishing an encrypted HTTP connection is HTTPS.^[22] Two other methods for establishing an encrypted HTTP connection also exist: Secure Hypertext Transfer Protocol, and using the HTTP/1.1 Upgrade header to specify an upgrade to TLS. Browser support for these two is, however, nearly non-existent.^[23][24][25]

This section describes messages for HTTP/1.1. Later versions, HTTP/2^[26] and HTTP/3, use a binary protocol, where headers are encoded in a single HEADERS and zero or more CONTINUATION frames using HPACK^[27] (HTTP/2) or QPACK (HTTP/3), which both provide efficient header compression. The request or response line from HTTP/1 has also been replaced by several pseudo-header fields, each beginning with a colon (:).

At the highest level, a message consists of a header followed by a body.

A header consists of lines of ASCIItext; each terminated with a carriage return and line feed sequence. The layout for both a request and a response header is:

Start line

Structured data that differs for request vs. response.

Header fields

Zero or more header field lines (at least 1 for HTTP/1.1); see below.

Empty line

Marks the end of the header.

A body consists of data in any format; not limited to ASCII. The format must match that specified by the Content-Type header field if the message contains one. A body is optional or, in other words, can be blank.

Before HTTP/2, the term entity was used to mean the body plus header fields that describe the body. In particular, not all headers were considered part of the entity. The term entity header referred to a header that was considered part of the entity, and sometimes the body was called the entity body. Modern documentation uses body and header without using entity.

A header field represents metadata about the containing message. Examples include how the body is encoded (via Content-Encoding), session verification and identification of the client (as in browser cookies, IP address, user-agent) or their anonymity thereof (VPN or proxy masking, user-agent spoofing), how the server should handle data (as in Do-Not-Track or Global Privacy Control), and the age (the time it has resided in a shared cache) of the document being downloaded. Generally, the information of a header field is used by software and not shown to the user.

A header field line is formatted as a name-value pair with a colon separator. Whitespace is not allowed around the name, but leading and trailing whitespace is ignored for the value part. Unlike a method name that must match exactly (case-sensitive),^[28] a header field name is matched ignoring case although often shown with each word capitalized.^[29] For example, the following are header fields for Host and Accept-Language.

Host: www.example.com Accept-Language: en 

The standards do not limit the size of a header field or the number of fields in a message. However, most servers, clients, and proxy software impose limits for practical and security reasons. For example, the Apache 2.3 server by default limits the size of each field to 8190 bytes, and there can be at most 100 header fields in a single request.^[30]

Although deprecated by RFC 7230,^[31] in the past, long lines could be split into multiple lines with a continuation line starting with a space or tab character.

A request is sent by a client to a server. The start line includes a method name, a request URI and the protocol version with a single space between each field.^[32] The following request start line specifies method GET, URI /customer/123 and protocol version HTTP/1.1:

GET /customer/123 HTTP/1.1 

Request header fields allow the client to pass additional information beyond the request line, acting as request modifiers (similarly to the parameters of a procedure). They give information about the client, about the target resource, or about the expected handling of the request. In the HTTP/1.1 protocol, all header fields except Host are optional.

Um die Kompatibilität mit HTTP-Clients vor der HTTP/1.0-Spezifikation in RFC 1945 zu gewährleisten , akzeptieren Server auch eine Anfragezeile, die nur den Pfadnamen enthält. ^{[ 33 ]} 

Das Protokoll strukturiert Transaktionen als Operationen auf Ressourcen. Was eine Ressource repräsentiert – ob bereits vorhandene oder dynamisch generierte Daten – hängt von der Serverimplementierung ab. Häufig entspricht die Ressource einer Datei oder der Ausgabe einer auf dem Server ausgeführten Anwendung.

Eine Anfrage identifiziert eine Methode (manchmal informell als Verb bezeichnet ), um die gewünschte Aktion für eine Ressource zu klassifizieren. Die HTTP/1.0-Spezifikation ^{[ 3 ] : §8} definierte die Methoden GET, HEAD und POST und führte die Methoden PUT, DELETE, LINK und UNLINK unter den zusätzlichen Methoden auf. Die HTTP/1.1-Spezifikation ^{[ 34 ] : §9} fügte fünf neue Methoden hinzu: PUT, DELETE, CONNECT, OPTIONS und TRACE. Jeder Client kann jede Methode verwenden, und der Server kann so konfiguriert werden, dass er jede beliebige Kombination von Methoden unterstützt. Ist eine Methode einem Zwischenschritt unbekannt, wird sie als unsicher und nicht idempotent behandelt . Die Anzahl der definierbaren Methoden ist unbegrenzt, sodass zukünftige Methoden spezifiziert werden können, ohne die bestehende Infrastruktur zu beeinträchtigen. Beispielsweise definierte WebDAV sieben neue Methoden, und RFC 5789 spezifizierte die PATCH- Methode. Ein universeller Webserver muss mindestens die Methoden GET und HEAD implementieren; alle anderen Methoden gelten laut Spezifikation als optional. ^{[ 18 ] : §9.1}  

Methodennamen unterscheiden Groß- und Kleinschreibung. ^{[ 4 ] : §3 [ 18 ] : §9.1} Dies steht im Gegensatz zu HTTP-Header-Feldnamen, die nicht zwischen Groß- und Kleinschreibung unterscheiden. ^{[ 18 ] : §6.3}

ERHALTEN

Die Anfrage bezieht sich auf die Repräsentation einer Ressource. Der Server soll lediglich Daten abrufen und den Zustand nicht verändern. ^{[ 1 ]} Für den unveränderten Abruf ist GET gegenüber POST vorzuziehen, da es über eine URL adressiert werden kann . Dies ermöglicht das Setzen von Lesezeichen und das Teilen von Inhalten und macht GET-Antworten für das Caching geeignet , wodurch Bandbreite gespart werden kann. Das W3C hat hierzu Leitlinien veröffentlicht und erklärt: „ Das Design von Webanwendungen sollte sich an den oben genannten Prinzipien, aber auch an den entsprechenden Einschränkungen orientieren.“ ^{[ 35 ]}

KOPF

Die Anfrage ähnelt einer GET-Anfrage, mit dem Unterschied, dass die Antwort die Repräsentationsdaten nicht im Antworttext enthalten soll. Dies ist nützlich, um die Repräsentationsmetadaten im Antwortheader abzurufen , ohne die gesamte Repräsentation übertragen zu müssen. Anwendungsbeispiele sind die Überprüfung der Verfügbarkeit einer Seite über den Statuscode und die Ermittlung der Dateigröße über ein Headerfeld Content-Length.

POST

Die Anfrage dient der Verarbeitung einer Ressource. Sie wird beispielsweise verwendet, um einen Beitrag in einem Internetforum zu veröffentlichen , eine Mailingliste zu abonnieren oder eine Online-Shopping- Transaktion abzuschließen. ^{[ 18 ] : §9.3.3}

SETZEN

Die Anfrage dient dazu, eine Ressource mit dem in der Anfrage angegebenen Zustand zu erstellen oder zu aktualisieren. Im Unterschied zu POST gibt der Client den Zielort auf dem Server an. ^{[ 18 ] : §9.3.4}

LÖSCHEN

Die Anfrage betrifft das Löschen einer Ressource.

VERBINDEN

Fordert den Vermittler auf, einen TCP/IP-Tunnel zum durch das Anfrageziel identifizierten Ursprungsserver herzustellen. Dies wird häufig verwendet, um Verbindungen über einen oder mehrere HTTP-Proxys mit TLS zu sichern . ^{[ 18 ] : §9.3.6 [ 36 ]} Siehe HTTP-CONNECT-Methode .

Optionen

Diese Anfrage dient der Auflistung der für eine Ressource unterstützten HTTP-Methoden. Sie kann genutzt werden, um die Funktionalität eines Webservers zu überprüfen, indem anstelle einer bestimmten Ressource ein Sternchen (*) angefordert wird.

VERFOLGEN

Der Server wird aufgefordert, die empfangene Anfrage im Antworttext zu übermitteln. Dadurch kann der Client erkennen, welche Änderungen oder Ergänzungen gegebenenfalls von Zwischenservern vorgenommen wurden. Dies ist hilfreich für die Fehlersuche.

PATCH

Die Anfrage dient dazu, eine Ressource entsprechend ihrem Teilzustand in der Anfrage zu modifizieren. Im Vergleich zu PUT kann dadurch Bandbreite gespart werden, da nur ein Teil der Ressourcendarstellung anstatt der gesamten Ressource gesendet wird. ^{[ 37 ]}

Eine Anfragemethode gilt als sicher, wenn eine Anfrage mit dieser Methode keine beabsichtigten Auswirkungen auf den Server hat. Die Methoden GET, HEAD, OPTIONS und TRACE sind als sicher definiert. Mit anderen Worten: Sichere Methoden sind für den Lesezugriff vorgesehen . Dennoch können sichere Methoden Nebenwirkungen haben , die für den Client nicht sichtbar sind, wie beispielsweise das Hinzufügen von Anfrageinformationen zu einer Protokolldatei oder die Belastung eines Werbekontos .

Im Gegensatz dazu sind die Methoden POST, PUT, DELETE, CONNECT und PATCH unsicher. Sie können den Zustand des Servers verändern oder andere Auswirkungen haben, wie beispielsweise das Versenden einer E-Mail . Solche Methoden werden daher üblicherweise nicht von konformen Webrobotern oder Webcrawlern verwendet; einige, die nicht konform sind, neigen dazu, Anfragen ohne Rücksicht auf Kontext oder Konsequenzen zu stellen.

Trotz der vorgeschriebenen Sicherheit von GET-Anfragen ist deren Verarbeitung durch den Server in der Praxis technisch nicht eingeschränkt. Nachlässige oder absichtlich fehlerhafte Programmierung kann dazu führen, dass GET-Anfragen erhebliche Änderungen auf dem Server verursachen. Dies ist unerwünscht, da Probleme auftreten können, wenn Web-Caching , Suchmaschinen und andere automatisierte Prozesse unbeabsichtigte Änderungen auf dem Server vornehmen. Beispielsweise könnte eine Website das Löschen einer Ressource über eine URL wie https://example.com/article/1234/delete ermöglichen . Würde diese URL beliebig aufgerufen, selbst per GET, würde der Artikel einfach gelöscht. ^{[ 38 ]} Eine korrekt programmierte Website würde für diese Aktion eine DELETE- oder POST-Methode erfordern, die von nicht-bösartigen Bots nicht verwendet wird.

Ein praktisches Beispiel hierfür war die kurzlebige Betaversion des Google Web Accelerator , die beliebige URLs auf der vom Nutzer angezeigten Seite vorab lud, was dazu führte, dass Datensätze massenhaft automatisch geändert oder gelöscht wurden . Die Betaversion wurde nach breiter Kritik nur wenige Wochen nach ihrer Veröffentlichung eingestellt. ^{[ 39 ]}

Eine Anfragemethode ist idempotent , wenn mehrere identische Anfragen mit dieser Methode die gleiche Wirkung haben wie eine einzelne Anfrage. Die Methoden PUT und DELETE sowie sichere Methoden gelten als idempotent. Sichere Methoden sind trivialerweise idempotent, da sie keinerlei Auswirkungen auf den Server haben sollen. Die Methoden PUT und DELETE sind idempotent, da aufeinanderfolgende identische Anfragen ignoriert werden. Eine Website könnte beispielsweise einen PUT-Endpunkt einrichten, um die gespeicherte E-Mail-Adresse eines Benutzers zu ändern. Wenn dieser Endpunkt korrekt konfiguriert ist, haben alle Anfragen, die die E-Mail-Adresse eines Benutzers auf dieselbe bereits gespeicherte Adresse ändern möchten – also doppelte Anfragen nach einer erfolgreichen Anfrage – keine Wirkung. Ebenso hat eine Anfrage zum Löschen eines bestimmten Benutzers keine Wirkung, wenn dieser Benutzer bereits gelöscht wurde.

Im Gegensatz dazu sind die Methoden POST, CONNECT und PATCH nicht notwendigerweise idempotent. Daher kann das mehrfache Senden einer identischen POST-Anfrage den Zustand des Servers verändern oder weitere Auswirkungen haben, wie beispielsweise das Versenden mehrerer E-Mails . In manchen Fällen ist dies erwünscht, in anderen Fällen kann es jedoch unbeabsichtigt auftreten. Ein Benutzer könnte beispielsweise versehentlich mehrere POST-Anfragen senden, indem er erneut auf eine Schaltfläche klickt, wenn er keine eindeutige Rückmeldung darüber erhält, dass der erste Klick verarbeitet wird. Webbrowser zeigen zwar unter Umständen Warnmeldungen an, um Benutzer darauf hinzuweisen, dass das Neuladen einer Seite eine erneute POST-Anfrage auslösen könnte, im Allgemeinen ist es jedoch Aufgabe der Webanwendung, Fälle zu behandeln, in denen eine POST-Anfrage nicht mehrfach gesendet werden soll.

Beachten Sie, dass die Idempotenz einer Methode weder vom Protokoll noch vom Webserver erzwungen wird. Es ist durchaus möglich, eine Webanwendung zu entwickeln, in der beispielsweise ein Datenbankeintrag oder eine andere nicht-idempotente Aktion durch eine GET-Anfrage oder eine andere Anfrage ausgelöst wird. Dies entgegen den Empfehlungen zu tun, kann jedoch unerwünschte Folgen haben, wenn ein Benutzeragent fälschlicherweise annimmt, dass die Wiederholung derselben Anfrage sicher ist.

Eine Anfragemethode ist zwischenspeicherbar, wenn Antworten auf Anfragen mit dieser Methode zur späteren Wiederverwendung gespeichert werden können. Die Methoden GET, HEAD und POST sind als zwischenspeicherbar definiert.

Im Gegensatz dazu sind die Methoden PUT, DELETE, CONNECT, OPTIONS, TRACE und PATCH nicht zwischenspeicherbar.

Der Server sendet eine Antwort an den Client. Die erste Zeile einer Antwort besteht aus der Protokollversion, einem Statuscode und optional einer Begründungsphrase. Die einzelnen Felder sind durch ein Leerzeichen getrennt. ^{[ 4 ] : §2.1} Die folgende Antwortzeile enthält die Protokollversion HTTP/1.1, den Statuscode 400und die Begründungsphrase Bad Request.

HTTP/1.1 400 Ungültige Anfrage 

Die Antwortheaderfelder ermöglichen es dem Server, über die Statuszeile hinaus zusätzliche Informationen zu übermitteln und fungieren somit als Antwortmodifikatoren. Sie liefern Informationen über den Server oder über den weiteren Zugriff auf die Zielressource bzw. verwandte Ressourcen. Jedes Antwortheaderfeld hat eine definierte Bedeutung, die durch die Semantik der Anfragemethode oder des Antwortstatuscodes weiter präzisiert werden kann.

Der Statuscode ist ein dreistelliger Dezimalwert, der den Status der Serveranfrage an den Client angibt. Im Allgemeinen verarbeitet ein Client eine Antwort primär anhand des Statuscodes und sekundär anhand der Antwortheader. Ein Client muss nicht jeden vom Server gemeldeten Statuscode verstehen, aber er muss die Klasse, die durch die erste Ziffer angegeben wird, erkennen und einen unbekannten Code als äquivalent zum x00-Code dieser Klasse behandeln. Die Klassen sind wie folgt:

1XX Informationsseite

Die Anfrage ist eingegangen, die Bearbeitung wird fortgesetzt.

2XX erfolgreich

Die Anfrage wurde erfolgreich empfangen, verstanden und angenommen.

3XX-Weiterleitung

Um den Antrag abzuschließen, sind weitere Maßnahmen erforderlich.

4XX-Clientfehler

Die Anfrage kann aufgrund eines Problems, das der Kunde möglicherweise beeinflussen kann, nicht erfüllt werden.

5XX-Serverfehler

Der Server konnte eine offenbar gültige Anfrage nicht bearbeiten.

Die Standard-Fehlermeldungen sind lediglich Empfehlungen. Ein Webserver darf eine lokalisierte Entsprechung verwenden. Weist ein Statuscode auf ein Problem hin, kann der Browser dem Benutzer die Fehlermeldung anzeigen, um weitere Informationen zur Art des Problems bereitzustellen. Der Standard erlaubt dem Browser auch, die Fehlermeldung zu interpretieren, was jedoch unklug sein kann, da der Standard ausdrücklich festlegt, dass Statuscodes maschinenlesbar und Fehlermeldungen menschenlesbar sind .

Das folgende Beispiel veranschaulicht eine HTTP/1.1-Anfrage-Antwort-Transaktion für einen Server unter www.example.com , Port 80. HTTP/1.0 würde dieselben Nachrichten verwenden, allerdings mit einigen fehlenden Headern. HTTP/2 und HTTP/3 verwenden denselben Anfrage-Antwort-Mechanismus, jedoch mit unterschiedlichen Darstellungen der HTTP-Header.

Im Folgenden finden Sie eine Anfrage ohne Inhalt. Sie besteht aus einer Startzeile, sechs Header-Feldern und einer Leerzeile – jeweils abgeschlossen durch einen Zeilenumbruch . Das Header-Feld dient der Unterscheidung verschiedener DNS- Namen, die sich eine einzige IP-Adresse teilen, und ermöglicht so namensbasiertes virtuelles Hosting . Während es in HTTP/1.0 optional war, ist es in HTTP/1.1 obligatorisch. Host

GET / HTTP / 1.1 Host : www.example.com User-Agent : Mozilla/5.0 Accept : text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language : en-GB,en;q=0.5 Accept-Encoding : gzip, deflate, br Connection : keep-alive

Obwohl dies in der obigen Darstellung (aufgrund der Beschränkungen dieses Wikis) nicht deutlich wird, führt die Leerzeile am Ende zu zwei Zeilenumbruchsequenzen. Dargestellt als Zeichenstrom, verdeutlicht eine verkürzte Version des obigen Beispiels dies besser, wobei <CRLF>eine Zeilenumbruchsequenz dargestellt wird: GET / HTTP/1.1<CRLF>Host: www.example.com<CRLF><CRLF>.

In der folgenden Antwort wird das ETag -Headerfeld (Entity Tag) verwendet, um festzustellen, ob eine zwischengespeicherte Version der angeforderten Ressource mit der aktuellen Version auf dem Server identisch ist. Das Content-TypeHeaderfeld spezifiziert den Internet-Medientyp der per HTTP-Nachricht übermittelten Daten und Content-Lengthgibt deren Länge in Bytes an. Der HTTP/1.1- Webserver signalisiert seine Fähigkeit, Anfragen nach einem Bytebereich der Ressource zu beantworten, indem er die Option `--byte-area` einbindet . Dies ist nützlich, wenn der Client nur bestimmte Teile ^{[ 40 ]} einer Ressource vom Server Accept-Ranges: bytesbenötigt , was als Byte-Serving bezeichnet wird . Wenn `--byte- area` gesendet wird, bedeutet dies, dass der Webserver die TCP- Verbindung unmittelbar nach dem Ende der Übertragung dieser Antwort schließt . ^{[ 4 ] : ​​§9.1} Connection: close

Die meisten Header-Felder sind optional, einige jedoch obligatorisch. Content-LengthFehlt der Header in einer Antwort mit Body, gilt dies in HTTP/1.0 als Fehler, in HTTP/1.1 hingegen nicht, sofern der Header Transfer-Encoding: chunkedvorhanden ist. Die Chunked Transfer Encoding verwendet eine Chunk-Größe von 0, um das Ende des Inhalts zu markieren. Einige ältere HTTP/1.0-Implementierungen ließen den Header weg, Content-Lengthwenn die Länge des Bodys zu Beginn der Antwort unbekannt war. Dadurch wurde die Datenübertragung zum Client fortgesetzt, bis der Server die Socket-Verbindung schloss.

Content-Encoding: gzipInformiert den Client darüber, dass der Inhalt gemäß dem gzip- Algorithmus komprimiert wurde .

HTTP / 1.1 200 OK Datum : Mo., 23. Mai 2005 22:38:34 GMT Content-Type : text/html; charset=UTF-8 Content-Length : 155 Last-Modified : Mi., 8. Jan. 2003 23:11:55 GMT Server : Apache/1.3.3.7 (Unix) (Red-Hat/Linux) ETag : "3f80f-1b6-3e1cb03b" Accept-Ranges : bytes Connection : close<html> <head> <title> Eine Beispielseite </title> </head> <body> <p> Hallo Welt , dies ist ein sehr einfaches HTML - Dokument . </p> </body> </html>​​​​​​​​

Gopher-Protokoll

Ein Content-Delivery-Protokoll, das Anfang der 1990er Jahre von HTTP abgelöst wurde.

SPDY -Protokoll

Eine bei Google entwickelte Alternative zu HTTP , die von HTTP/2 abgelöst wurde .

Gemini-Protokoll

Ein von Gopher inspiriertes Protokoll, das datenschutzbezogene Funktionen vorschreibt.

Tim Berners-Lee und sein Team am CERN gelten als Erfinder von HTTP sowie von HTML und der zugehörigen Technologie für einen Webserver und eine Client -Benutzeroberfläche , den sogenannten Webbrowser . Berners-Lee entwickelte HTTP, um die Verbreitung seiner anderen Idee zu fördern: das „WorldWideWeb“-Projekt, das erstmals 1989 vorgeschlagen wurde und heute als World Wide Web bekannt ist . Die Entwicklung von HTTP begann 1989 und wurde in einem einfachen Dokument zusammengefasst, das das Verhalten eines Clients und eines Servers unter Verwendung der ersten HTTP-Version 0.9 beschrieb. ^{[ 41 ]} Diese Version wurde anschließend weiterentwickelt und schließlich zur öffentlichen Version 1.0. ^{[ 42 ]} Die Entwicklung der ersten HTTP- RFC-Dokumente ( Request for Comments ) begann einige Jahre später in einer koordinierten Anstrengung der Internet Engineering Task Force (IETF) und des World Wide Web Consortiums (W3C), wobei die Arbeit später an die IETF überging.

Der erste Webserver ging 1990 online. ^{[ 43 ] [ 44 ]} Das verwendete Protokoll kannte nur eine Methode, nämlich GET, mit der eine Seite vom Server angefordert wurde. ^{[ 45 ]} Die Antwort des Servers war immer eine HTML-Seite. ^{[ 41 ]}

1991 wurde die erste dokumentierte offizielle Version von HTTP als einfaches Dokument mit weniger als 700 Wörtern verfasst. Diese Version erhielt die Bezeichnung HTTP/0.9 und unterstützte ausschließlich die GET-Methode, sodass Clients nur HTML-Dokumente vom Server abrufen konnten. Andere Dateiformate oder das Hochladen von Informationen wurden nicht unterstützt. ^{[ 41 ]}

Seit 1992 wurde ein neues Dokument verfasst, um die Weiterentwicklung des Basisprotokolls hin zur nächsten vollständigen Version zu spezifizieren. Es unterstützte sowohl die einfache Anfragemethode der Version 0.9 als auch die vollständige GET-Anfrage, die die Client-HTTP-Version umfasste. Dies war der erste der vielen inoffiziellen HTTP/1.0-Entwürfe, die der endgültigen Entwicklung von HTTP/1.0 vorausgingen. ^{[ 42 ]}

Nachdem entschieden worden war, dass neue Funktionen des HTTP-Protokolls erforderlich seien und diese vollständig als offizielle RFC-Dokumente dokumentiert werden müssten, wurde Anfang 1995 die HTTP Working Group (HTTP WG, unter der Leitung von Dave Raggett ) gegründet. Ziel war die Standardisierung und Erweiterung des Protokolls um erweiterte Operationen, eine erweiterte Aushandlung, umfangreichere Metainformationen sowie ein Sicherheitsprotokoll, das durch zusätzliche Methoden und Header-Felder effizienter gestaltet werden sollte . ^{[ 46 ] [ 47 ]}

Die HTTP-Arbeitsgruppe plante, innerhalb des Jahres 1995 neue Versionen des Protokolls als HTTP/1.0 und HTTP/1.1 zu überarbeiten und zu veröffentlichen, aber aufgrund der vielen Überarbeitungen dauerte dieser Zeitplan weit länger als ein Jahr. ^{[ 48 ]}

Die HTTP-Arbeitsgruppe plante außerdem, eine weit zukünftige Version von HTTP namens HTTP-NG (HTTP Next Generation) zu spezifizieren, die alle verbleibenden Probleme der vorherigen Versionen in Bezug auf Leistung, niedrige Latenzzeiten usw. gelöst hätte. Diese Arbeiten begannen jedoch erst einige Jahre später und wurden nie abgeschlossen.

Im Mai 1996 wurde RFC  1945 ^{[ 3 ]} als endgültige HTTP/1.0-Revision veröffentlicht. Der Entwurf, der in den vier Jahren zuvor als Vorstandard für HTTP/1.0 verwendet worden war, wurde bereits von vielen Webbrowsern und Webservern genutzt.

Anfang 1996 begannen Entwickler sogar, inoffizielle Erweiterungen des HTTP/1.0-Protokolls (z. B. Keep-Alive-Verbindungen) in ihre Produkte zu integrieren, indem sie Entwürfe der kommenden HTTP/1.1-Spezifikationen verwendeten. ^{[ 20 ]}

Seit Anfang 1996 begannen auch die führenden Webbrowser- und Webserver-Entwickler, neue Funktionen zu implementieren, die in den Entwürfen der Vorstandard-Spezifikationen von HTTP/1.1 spezifiziert waren. Die neuen Browser- und Serverversionen wurden von den Endnutzern schnell angenommen. Im März 1996 berichtete ein Webhosting-Unternehmen, dass über 40 % der im Internet verwendeten Browser den neuen HTTP/1.1-Header „Host“ für virtuelles Hosting nutzten und dass bis Juni 1996 65 % aller Browser, die auf ihre Server zugriffen, mit den Vorstandard-Spezifikationen von HTTP/1.1 kompatibel waren. ^{[ 49 ]}

Im Januar 1997 wurde RFC  2068 ^{[ 50 ] offiziell als HTTP/1.1-Spezifikation veröffentlicht.}

Im Juni 1999 wurde RFC  2616 ^{[ 34 ]} veröffentlicht, um alle Verbesserungen und Aktualisierungen auf der Grundlage der vorherigen (veralteten) HTTP/1.1-Spezifikationen zu beinhalten.

In Anlehnung an den alten Plan der vorherigen HTTP-Arbeitsgruppe von 1995 wurde 1997 die HTTP-NG-Arbeitsgruppe gegründet, um ein neues HTTP-Protokoll namens HTTP-NG (HTTP New Generation) zu entwickeln. Es wurden einige Vorschläge/Entwürfe für das neue Protokoll erstellt, die die Multiplexierung von HTTP-Transaktionen innerhalb einer einzigen TCP/IP-Verbindung vorsahen. 1999 stellte die Gruppe jedoch ihre Tätigkeit ein und übergab die technischen Probleme an die IETF. ^{[ 51 ]}

Im Jahr 2007 wurde die IETF HTTP Working Group (HTTP WG bis oder HTTPbis) neu gegründet, um erstens die vorherigen HTTP/1.1-Spezifikationen zu überarbeiten und zu präzisieren und zweitens die zukünftigen HTTP/2-Spezifikationen (httpbis) zu verfassen und zu verfeinern. ^{[ 52 ] [ 53 ]}

Im Jahr 2009 kündigte Google SPDY an – ein von ihnen entwickeltes Binärprotokoll zur Beschleunigung des Webverkehrs zwischen Browsern und Servern. In zahlreichen Tests erwies sich SPDY tatsächlich als schneller als HTTP/1.1. SPDY wurde in Googles Chromium und anschließend in weitere gängige Webbrowser integriert. ^{[ 54 ]} Einige der Ideen zum Multiplexen von HTTP-Streams über eine einzelne TCP-Verbindung stammten aus verschiedenen Quellen, darunter die Arbeit der W3C HTTP-NG Working Group.

Im Jahr 2012 kündigte die HTTP Working Group (HTTPbis) die Notwendigkeit eines neuen Protokolls an. Zunächst wurden Aspekte von SPDY ^{[ 55 ] [ 56 ]} berücksichtigt , schließlich entschied man sich jedoch, das neue Protokoll von SPDY abzuleiten. ^{[ 57 ]} Im Mai 2015 wurde HTTP/2 als RFC  7540 veröffentlicht ^{[ 58 ]} . Das Protokoll wurde von Webbrowsern, die SPDY bereits unterstützten, schnell übernommen, von Webservern hingegen etwas langsamer.

Im Juni 2014 veröffentlichte die HTTP Working Group eine aktualisierte sechsteilige HTTP/1.1-Spezifikation, die RFC  2616 ^{[ 34 ]} überflüssig machte :

• RFC  7230 – " Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, " ^{[ 59 ]} Veraltet.
• RFC  7231 – " Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, " ^{[ 60 ]} Veraltet.
• RFC  7232 – " Hypertext Transfer Protocol (HTTP/1.1): Bedingte Anfragen, " ^{[ 61 ]} Veraltet.
• RFC  7233 – " Hypertext Transfer Protocol (HTTP/1.1): Bereichsanforderungen, " ^{[ 62 ]} Veraltet.
• RFC  7234 – " Hypertext Transfer Protocol (HTTP/1.1): Caching, " ^{[ 63 ]} Veraltet.
• RFC  7235 – " Hypertext Transfer Protocol (HTTP/1.1): Authentication, " ^{[ 64 ]} Veraltet.

Im Jahr 2014 wurde HTTP/0.9 für Server, die HTTP/1.1 (und höher) unterstützen, als veraltet eingestuft: ^{[ 59 ] : §Anhang A}

Da HTTP/0.9 keine Header-Felder in Anfragen unterstützte, gibt es keinen Mechanismus für namensbasierte virtuelle Hosts (Ressourcenauswahl durch Prüfung des Host-Header-Felds). Jeder Server, der namensbasierte virtuelle Hosts implementiert, sollte die Unterstützung für HTTP/0.9 deaktivieren . Die meisten Anfragen, die wie HTTP/0.9-Anfragen aussehen, sind in Wirklichkeit fehlerhafte HTTP/1.x-Anfragen, die dadurch verursacht werden, dass der Client das Anfrageziel nicht korrekt kodiert hat.

Seit 2016 planen viele Produktmanager und Entwickler von Benutzeragenten (Browsern usw.) und Webservern, die Unterstützung für das HTTP/0.9-Protokoll schrittweise einzustellen und abzuschaffen, hauptsächlich aus folgenden Gründen: ^{[ 65 ]}

• Es ist so einfach, dass nie ein RFC-Dokument verfasst wurde (es existiert nur das Originaldokument); ^{[ 41 ]}
• Es verfügt über keine HTTP-Header und weist viele weitere Mängel auf, die heutzutage aus Gründen der minimalen Sicherheit erforderlich sind;
• Seit 1999/2000 ist es nicht mehr weit verbreitet (wegen HTTP/1.0 und HTTP/1.1) und wird üblicherweise nur noch von sehr alten Netzwerkgeräten wie Routern usw. verwendet.

Stand 2022 ist die Unterstützung für HTTP/0.9 noch nicht offiziell und vollständig eingestellt und wird weiterhin von vielen Webservern und Browsern (nur für Serverantworten) unterstützt, auch wenn sie üblicherweise deaktiviert ist. Es ist unklar, wie lange die endgültige Abschaffung von HTTP/0.9 dauern wird.

Im Jahr 2020 wurden die ersten Entwürfe von HTTP/3 veröffentlicht, und die wichtigsten Webbrowser und Webserver begannen, es zu übernehmen. Am 6. Juni 2022 standardisierte die IETF HTTP/3 als RFC  9114 ^{[ 66 ]} .

Im Juni 2022 wurden RFC-Dokumente veröffentlicht, die viele der vorherigen Dokumente als veraltet erklärten und einige kleinere Änderungen sowie eine Umstrukturierung der HTTP-Semantikbeschreibung in ein separates Dokument einführten.

• RFC  9110 – " HTTP Semantics, " ^{[ 18 ]} Internet Standard 97.
• RFC  9111 – " HTTP Caching, " ^{[ 67 ]} Internet Standard 98.
• RFC  9112 – " HTTP/1.1, " ^{[ 4 ]} Internet Standard 99.
• RFC  9113 – " HTTP/2, " ^{[ 6 ]} Vorgeschlagener Standard.
• RFC  9114 – " HTTP/3, " ^{[ 66 ]} Vorgeschlagener Standard. (Siehe auch den obigen Abschnitt.)
• RFC  9204 – " QPACK: Feldkomprimierung für HTTP/3, " ^{[ 68 ]} Vorgeschlagener Standard.
• RFC  9218 – " Erweiterbares Priorisierungsschema für HTTP, " ^{[ 69 ]} Vorgeschlagener Standard.

• Vergleich von Dateiübertragungsprotokollen
• Constrained Application Protocol  – Spezialisiertes Internet-Anwendungsprotokoll
• Inhaltsverhandlung  – Bereitstellung mehrerer Dokumente unter derselben URI
• Digest-Zugriffsauthentifizierung  – Methode zur Aushandlung von Anmeldeinformationen zwischen Webserver und Browser
• InterPlanetary File System  – Inhaltsadressierbares Peer-to-Peer-Hypermedia-Verteilungsprotokoll
• HTTP-Komprimierung  – Eine Funktion, die in Webserver und Webclients integriert werden kann.
• Repräsentativer Zustandstransfer  – Architekturstil für Client-Server-AnwendungenSeiten mit Kurzbeschreibungen der Weiterleitungsziele
• Variant-Objekt
• Web-Cache  – System zur Optimierung des Webs
• WebSocket  – Computernetzwerkprotokoll
• Wireless Application Protocol  – Veralteter technischer Standard für den Datenzugriff über ein Mobilfunknetz

• Offizielle Website
• IETF HTTP Working Group auf GitHub
• „Änderungshistorie für HTTP“ . W3.org . Abgerufen am 1. August 2010 .Eine detaillierte technische Geschichte von HTTP.
• „Designfragen für HTTP“ . W3.org . Abgerufen am 1. August 2010 .Designprobleme von Berners-Lee bei der Entwicklung des Protokolls.