1. Introduction (Einführung)
1.1 Purpose (Zweck)
Das Hypertext-Übertragungsprotokoll (Hypertext Transfer Protocol, HTTP) ist ein Protokoll auf Anwendungsebene für verteilte, kollaborative Hypermedia-Informationssysteme. HTTP wird seit 1990 von der World-Wide-Web-Initiative für globale Informationen verwendet. Die erste Version von HTTP, genannt HTTP/0.9, war ein einfaches Protokoll für die Übertragung von Rohdaten über das Internet. HTTP/1.0, definiert in RFC 1945 [6], verbesserte das Protokoll, indem es Nachrichten in einem MIME-ähnlichen Nachrichtenformat ermöglichte, das Metadaten über die übertragenen Daten sowie Modifikatoren für die Anfrage/Antwort-Semantik enthält. HTTP/1.0 berücksichtigte jedoch nicht ausreichend die Auswirkungen von hierarchischen Proxies, Caching, persistenten Verbindungen oder virtuellen Hosts. Darüber hinaus bezeichneten sich viele Anwendungen mit unvollständigen Implementierungen als "HTTP/1.0", was eine Änderung der Protokollversion erforderlich machte, damit zwei kommunizierende Anwendungen die tatsächlichen Fähigkeiten des jeweils anderen bestimmen können.
Diese Spezifikation definiert das als "HTTP/1.1" bezeichnete Protokoll. Dieses Protokoll enthält strengere Anforderungen als HTTP/1.0, um eine zuverlässige Implementierung seiner Funktionen zu gewährleisten.
Praktische Informationssysteme benötigen mehr Funktionen als nur einfaches Abrufen, einschließlich Suche, Frontend-Updates und Annotationen. HTTP ermöglicht ein offenes Set von Methoden und Header-Feldern zur Angabe des Zwecks einer Anfrage [47]. Es baut auf der von Uniform Resource Identifier (URI) [3] bereitgestellten Referenzspezifikation auf, als Standort (URL) [4] oder Name (URN) [20], um die Ressource anzugeben, auf die die Methode angewendet werden soll. Nachrichten werden in einem Format übertragen, das dem von Internet-Mail [9] verwendeten ähnelt, wie es durch Multipurpose Internet Mail Extensions (MIME) [7] definiert ist.
HTTP wird auch als generisches Protokoll für die Kommunikation zwischen Benutzeragenten und Proxies/Gateways zu anderen Internetsystemen verwendet, einschließlich solcher, die von den Protokollen SMTP [16], NNTP [13], FTP [18], Gopher [2] und WAIS [10] unterstützt werden. Auf diese Weise ermöglicht HTTP einen grundlegenden Hypermedia-Zugriff auf verfügbare Ressourcen aus verschiedenen Anwendungen.
1.2 Requirements (Anforderungen)
Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in RFC 2119 [34] beschrieben zu interpretieren.
Eine Implementierung ist nicht konform, wenn sie eine oder mehrere MUST- oder REQUIRED-Anforderungen des von ihr implementierten Protokolls nicht erfüllt. Eine Implementierung, die alle MUST- oder REQUIRED-Anforderungen sowie alle SHOULD-Anforderungen ihres Protokolls erfüllt, wird als "bedingungslos konform" (unconditionally compliant) bezeichnet. Eine Implementierung, die alle MUST-Anforderungen, aber nicht alle SHOULD-Anforderungen ihres Protokolls erfüllt, wird als "bedingt konform" (conditionally compliant) bezeichnet.
1.3 Terminology (Terminologie)
Diese Spezifikation verwendet zahlreiche Begriffe, um die Rollen zu bezeichnen, die von Teilnehmern und Objekten in der HTTP-Kommunikation gespielt werden.
connection (Verbindung) Eine virtuelle Transportschicht-Schaltung, die zwischen zwei Programmen zu Kommunikationszwecken hergestellt wird.
message (Nachricht) Die Grundeinheit der HTTP-Kommunikation, bestehend aus einer strukturierten Sequenz von Oktetten, die der in Abschnitt 4 definierten Syntax entspricht und über eine Verbindung übertragen wird.
request (Anfrage) Eine HTTP-Anfragenachricht, wie in Abschnitt 5 definiert.
response (Antwort) Eine HTTP-Antwortnachricht, wie in Abschnitt 6 definiert.
resource (Ressource) Ein Netzwerkdatenobjekt oder -dienst, das durch einen URI identifiziert werden kann, wie in Abschnitt 3.2 definiert. Ressourcen können in mehreren Darstellungen verfügbar sein (z.B. mehrere Sprachen, Datenformate, Größen und Auflösungen) oder auf andere Weise variieren.
entity (Entität) Die als Nutzlast einer Anfrage oder Antwort übertragenen Informationen. Eine Entität besteht aus Metadaten in Form von Entitäts-Header-Feldern und Inhalt in Form eines Entitätskörpers, wie in Abschnitt 7 beschrieben.
representation (Darstellung) Eine in einer Antwort enthaltene Entität, die der Inhaltsverhandlung unterliegt, wie in Abschnitt 12 beschrieben. Es kann mehrere Darstellungen geben, die mit einem bestimmten Antwortstatus verbunden sind.
content negotiation (Inhaltsverhandlung) Der Mechanismus zur Auswahl der geeigneten Darstellung bei der Bearbeitung einer Anfrage, wie in Abschnitt 12 beschrieben. Die Darstellung von Entitäten in jeder Antwort kann verhandelt werden (einschließlich Fehlerantworten).
variant (Variante) Eine Ressource kann zu einem bestimmten Zeitpunkt eine oder mehrere Darstellungen haben. Jede dieser Darstellungen wird als "Variante" (variant) bezeichnet. Die Verwendung des Begriffs "Variante" impliziert nicht notwendigerweise, dass die Ressource der Inhaltsverhandlung unterliegt.
client (Client) Ein Programm, das eine Verbindung zum Zweck des Sendens von Anfragen herstellt.
user agent (Benutzeragent) Der Client, der eine Anfrage initiiert. Dies sind typischerweise Browser, Editoren, Web-Crawler (web-traversing robots) oder andere Endbenutzer-Tools.
server (Server) Eine Anwendung, die Verbindungen akzeptiert, um Anfragen durch Senden von Antworten zu bedienen. Jedes gegebene Programm kann sowohl Client als auch Server sein. Unsere Verwendung dieser Begriffe bezieht sich nur auf die Rolle, die das Programm für eine bestimmte Verbindung ausführt, und nicht auf die allgemeinen Fähigkeiten des Programms. Ebenso kann jeder Server als Ursprungsserver, Proxy, Gateway oder Tunnel fungieren, indem er sein Verhalten je nach Art jeder Anfrage ändert.
origin server (Ursprungsserver) Der Server, auf dem eine bestimmte Ressource residiert oder erstellt werden soll.
proxy (Proxy) Ein Zwischenprogramm, das sowohl als Server als auch als Client fungiert, um Anfragen im Namen anderer Clients zu stellen. Anfragen werden intern verarbeitet oder möglicherweise mit Übersetzung an andere Server weitergeleitet. Ein Proxy muss (MUST) sowohl die Client- als auch die Serveranforderungen dieser Spezifikation implementieren. Ein "transparenter Proxy" (transparent proxy) ist ein Proxy, der die Anfrage oder Antwort nicht über das für die Proxy-Authentifizierung und -Identifikation Erforderliche hinaus modifiziert. Ein "nicht-transparenter Proxy" (non-transparent proxy) ist ein Proxy, der die Anfrage oder Antwort modifiziert, um dem Benutzeragenten zusätzliche Dienste bereitzustellen, wie z.B. Gruppenannotationsdienste, Medientypkonvertierung, Protokollreduktion oder Anonymitätsfilterung. Sofern nicht ausdrücklich transparentes oder nicht-transparentes Verhalten angegeben ist, gelten die HTTP-Proxy-Anforderungen für beide Proxy-Typen.
gateway (Gateway) Ein Server, der als Vermittler für einen anderen Server fungiert. Im Gegensatz zu einem Proxy empfängt ein Gateway Anfragen, als ob es der Ursprungsserver für die angeforderte Ressource wäre. Der anfragende Client ist sich möglicherweise nicht bewusst, dass er mit einem Gateway kommuniziert.
tunnel (Tunnel) Ein Zwischenprogramm, das als Blind-Relay zwischen zwei Verbindungen fungiert. Sobald ein Tunnel aktiv ist, wird er nicht als Teil der HTTP-Kommunikation betrachtet, obwohl ein Tunnel möglicherweise durch eine HTTP-Anfrage initiiert wurde. Der Tunnel existiert nicht mehr, wenn beide Enden der weitergeleiteten Verbindungen geschlossen sind.
cache (Cache) Der lokale Speicher von Antwortnachrichten eines Programms und das Subsystem, das die Speicherung, den Abruf und das Löschen seiner Nachrichten steuert. Ein Cache speichert cachefähige Antworten, um die Antwortzeit und den Netzwerkbandbreitenverbrauch für zukünftige äquivalente Anfragen zu reduzieren. Jeder Client oder Server kann einen Cache enthalten, obwohl ein Server, der als Tunnel fungiert, keinen Cache verwenden kann.
cacheable (cachefähig) Eine Antwort ist cachefähig, wenn ein Cache berechtigt ist, eine Kopie der Antwortnachricht zu speichern, um sie zur Beantwortung nachfolgender Anfragen zu verwenden. Die Regeln zur Bestimmung, ob eine HTTP-Antwort cachefähig ist, sind in Abschnitt 13 definiert. Auch wenn eine Ressource cachefähig ist, kann es zusätzliche Einschränkungen geben, ob ein bestimmter Cache sie cachen sollte.
first-hand (aus erster Hand) Eine Antwort ist aus erster Hand, wenn sie vom Ursprungsserver stammt, möglicherweise über einen oder mehrere Proxies. Eine Antwort ist auch aus erster Hand, wenn ihre Gültigkeit direkt mit dem Ursprungsserver überprüft wurde.
explicit expiration time (explizite Ablaufzeit) Die Zeit, zu der der Ursprungsserver beabsichtigt, dass eine Entität nicht mehr von einem Cache ohne weitere Validierung zurückgegeben wird.
heuristic expiration time (heuristische Ablaufzeit) Eine Ablaufzeit, die von einem Cache in Abwesenheit einer expliziten Ablaufzeit zugewiesen wird.
age (Alter) Das Alter einer Antwort ist die Zeit seit dem Senden der Antwort durch den Ursprungsserver (oder der erfolgreichen Validierung der Antwort).
freshness lifetime (Frische-Lebensdauer) Die Zeitspanne zwischen der Generierung einer Antwort und ihrer Ablaufzeit.
fresh (frisch) Eine Antwort ist frisch, wenn ihr Alter ihre Frische-Lebensdauer noch nicht überschritten hat.
stale (veraltet) Eine Antwort ist veraltet, wenn ihr Alter ihre Frische-Lebensdauer überschritten hat.
semantically transparent (semantisch transparent) Ein Cache verhält sich semantisch transparent, wenn seine Verwendung weder den anfragenden Client noch den Ursprungsserver beeinflusst, außer zur Verbesserung der Leistung. Wenn ein Cache semantisch transparent arbeitet, erhält der Client genau dieselbe Antwort (außer Hop-by-Hop-Header-Feldern), die er erhalten hätte, wenn sie direkt vom Ursprungsserver gesendet worden wäre, und der Cache beeinflusst nicht die Verarbeitung nachfolgender Anfragen.
validator (Validator) Ein Protokollelement (z.B. ein Entity-Tag oder eine Last-Modified-Zeit), das verwendet wird, um festzustellen, ob ein Cache-Eintrag eine äquivalente Kopie einer Entität ist.
upstream/downstream (aufwärts/abwärts) Aufwärts und abwärts beschreiben den Nachrichtenfluss: Alle Nachrichten fließen von aufwärts nach abwärts.
inbound/outbound (eingehend/ausgehend) Eingehend und ausgehend beziehen sich auf Anfrage- und Antwortpfade in Bezug auf die Anfrage: "eingehend" bedeutet "zum Ursprungsserver hin", und "ausgehend" bedeutet "zum Benutzeragenten hin".
1.4 Overall Operation (Gesamtbetrieb)
Das HTTP-Protokoll ist ein Anfrage/Antwort-Protokoll. Ein Client sendet eine Anfrage an einen Server in Form einer Anfragemethode, eines URI und einer Protokollversion, gefolgt von einer MIME-ähnlichen Nachricht, die Anfrage-Modifikatoren, Client-Informationen und möglicherweise Body-Inhalt enthält, übertragen über eine Verbindung. Der Server antwortet mit einer Statuszeile, einschließlich der Protokollversion der Nachricht und einem Erfolgs- oder Fehlercode, gefolgt von einer MIME-ähnlichen Nachricht, die Serverinformationen, Entitäts-Metadaten und möglicherweise Entitätskörper-Inhalt enthält. Die meiste HTTP-Kommunikation wird von einem Benutzeragenten initiiert und besteht aus einer Anfrage für eine Ressource auf einem Ursprungsserver. Im einfachsten Fall kann dies über eine einzelne Verbindung (v) zwischen dem Benutzeragenten (UA) und dem Ursprungsserver (O) erreicht werden.
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain
Eine komplexere Situation tritt auf, wenn ein oder mehrere Vermittler in der Anfrage/Antwort-Kette vorhanden sind. Es gibt drei häufige Formen von Vermittlern: Proxy, Gateway und Tunnel. Ein Proxy ist ein Weiterleitungsagent, der Anfragen für einen URI in seiner absoluten Form empfängt, die gesamte oder einen Teil der Nachricht umschreibt und die umformatierte Anfrage an den durch den URI identifizierten Server weiterleitet. Ein Gateway ist ein Empfangsagent, der als Schicht über einem anderen Server fungiert und bei Bedarf Anfragen in das Protokoll des zugrunde liegenden Servers übersetzen kann. Ein Tunnel fungiert als Relaispunkt zwischen zwei Verbindungen, ohne die Nachrichten zu ändern. Tunnel werden verwendet, wenn die Kommunikation durch einen Vermittler (wie z.B. eine Firewall) erfolgen muss, selbst wenn der Vermittler den Inhalt der Nachrichten nicht verstehen kann.
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
Die obige Abbildung zeigt drei Vermittler (A, B und C) zwischen dem Benutzeragenten und dem Ursprungsserver. Eine Nachricht, die die gesamte Anfrage/Antwort-Kette durchläuft, verwendet den Weitergabemechanismus für HTTP-Kommunikationsoptionen, um die Parameter der Verbindung zu bestimmen.
Jede Partei, die nicht als Tunnel fungiert, kann einen Cache verwenden, um Anfragen zu erfüllen. Die Auswirkung eines Caches auf die Anfrage/Antwort-Kette hängt von den Caching-Anforderungen der verschiedenen Caches entlang der Kette ab, die die Anfrage oder Antwort abfangen können. Das Caching-Verhalten und cachefähige Antworten sind in Abschnitt 13 definiert.
In der Praxis gibt es verschiedene Konfigurationen von Architekturmustern im Internet und innerhalb von Organisationen. Beispielsweise verwendet ein "nationaler Zugangsprovider" typischerweise große Proxy-Caches, damit mehrere Benutzeragenten über dieselbe Anfragekette auf Ursprungsserver zugreifen können. Eine weitere gängige Konfiguration ist der "Reverse-Proxy"-Cache, der sich unter dem Hostnamen einer Organisation befindet, aber von deren Clients oder einem Dritten kontrolliert wird. Reverse-Proxy-Caches sind für Benutzeragenten transparent, werden aber häufig von Netzwerkanbietern verwaltet, um den über das Netzwerk laufenden Verkehr zu sparen.
HTTP-Kommunikation erfolgt in der Regel über TCP/IP-Verbindungen. Der Standardport ist TCP 80 [19], aber andere Ports können ebenfalls verwendet werden. Dies schließt die Implementierung von HTTP über andere Protokolle im Internet oder in anderen Netzwerken nicht aus. HTTP setzt lediglich einen zuverlässigen Transport voraus. Jedes Protokoll, das solche Garantien bietet, kann verwendet werden. Die Abbildung der HTTP/1.1-Anfrage- und Antwortstrukturen auf die Dateneinheiten eines gegebenen Transportprotokolls liegt außerhalb des Geltungsbereichs dieser Spezifikation.
In HTTP/1.0 schlossen die meisten Implementierungen die Verbindung nach jedem Anfrage/Antwort-Austausch. In HTTP/1.1 ermöglicht ein Mechanismus, wie in Abschnitt 8.1 beschrieben, die Verwendung derselben Verbindung für mehrere Anfrage/Antwort-Austausche unter Verwendung von "persistenten Verbindungen" (persistent connections).