3. Terminology and Core Concepts (Terminologie und Kernkonzepte)
HTTP wurde für die World Wide Web (WWW) Architektur geschaffen und hat sich im Laufe der Zeit weiterentwickelt, um die Skalierbarkeitsbedürfnisse eines weltweiten Hypertextsystems zu unterstützen. Ein Großteil dieser Architektur spiegelt sich in der Terminologie wider, die zur Definition von HTTP verwendet wird.
3.1. Resources (Ressourcen)
Das Ziel einer HTTP-Anfrage wird als "Ressource" (Resource) bezeichnet. HTTP begrenzt nicht die Natur einer Ressource; es definiert lediglich eine Schnittstelle, die zur Interaktion mit Ressourcen verwendet werden könnte. Die meisten Ressourcen werden durch einen Uniform Resource Identifier (URI) identifiziert, wie in Abschnitt 4 beschrieben.
Ein Designziel von HTTP ist es, die Ressourcenidentifikation von der Anfrage-Semantik zu trennen, was durch die Verankerung der Anfrage-Semantik in der Anfragemethode (Abschnitt 9) und einigen anfrage-modifizierenden Header-Feldern ermöglicht wird. Eine Ressource kann eine Anfrage nicht in einer Weise behandeln, die mit der Semantik der Methode der Anfrage inkonsistent ist. Zum Beispiel kann ein Client erwarten, dass die Ressource unsichere Aktionen vermeidet, wenn eine Anfrage mit einer sicheren Methode (Safe Method) verarbeitet wird (siehe Abschnitt 9.2.1), auch wenn der URI der Ressource eine nicht sichere Semantik implizieren könnte.
HTTP stützt sich auf den Uniform Resource Identifier (URI) Standard [URI], um die Zielressource (Abschnitt 7.1) und Beziehungen zwischen Ressourcen anzuzeigen.
3.2. Representations (Repräsentationen)
Eine "Repräsentation" (Representation) ist eine Information, die dazu bestimmt ist, einen vergangenen, aktuellen oder gewünschten Zustand einer gegebenen Ressource in einem Format widerzuspiegeln, das über das Protokoll leicht kommuniziert werden kann. Eine Repräsentation besteht aus einem Satz von Repräsentationsmetadaten (Representation Metadata) und einem potenziell unbegrenzten Strom von Repräsentationsdaten (Representation Data, Abschnitt 8).
HTTP ermöglicht "Informationsverschleierung" (Information Hiding) hinter seiner einheitlichen Schnittstelle, indem es die Kommunikation in Bezug auf eine übertragbare Repräsentation des Ressourcenzustands definiert, anstatt die Ressource selbst zu übertragen. Dies ermöglicht es, dass die durch einen URI identifizierte Ressource alles sein kann, einschließlich zeitlicher Funktionen wie "das aktuelle Wetter in Laguna Beach", während potenziell Informationen bereitgestellt werden, die diese Ressource zum Zeitpunkt der Nachrichtengenerierung darstellen [REST].
Die einheitliche Schnittstelle ist ähnlich einem Fenster, durch das man etwas nur durch die Kommunikation von Nachrichten an einen unabhängigen Akteur auf der anderen Seite beobachten und darauf einwirken kann. Eine gemeinsame Abstraktion ist erforderlich, um den aktuellen oder gewünschten Zustand dieser Sache in unseren Kommunikationen darzustellen ("den Platz einzunehmen"). Wenn eine Repräsentation ein Hypertext ist, kann sie sowohl eine Repräsentation des Ressourcenzustands als auch Verarbeitungsanweisungen bereitstellen, die helfen, die zukünftigen Interaktionen des Empfängers zu leiten.
Einer Zielressource können mehrere Repräsentationen bereitgestellt werden oder sie kann mehrere Repräsentationen generieren können, die jeweils dazu bestimmt sind, den aktuellen Zustand der Ressource widerzuspiegeln. Ein Algorithmus, der normalerweise auf Content-Negotiation (Content Negotiation, Abschnitt 12) basiert, würde verwendet werden, um eine dieser Repräsentationen als am besten auf eine gegebene Anfrage anwendbar auszuwählen. Diese "ausgewählte Repräsentation" (Selected Representation) liefert die Daten und Metadaten zur Bewertung bedingter Anfragen (Abschnitt 13) und zur Konstruktion des Inhalts für 200 (OK), 206 (Partial Content) und 304 (Not Modified) Antworten auf GET (Abschnitt 9.3.1).
3.3. Connections, Clients, and Servers (Verbindungen, Clients und Server)
HTTP ist ein Client/Server-Protokoll, das über eine zuverlässige Transport- oder Sitzungsschicht-"Verbindung" (Connection) operiert.
Ein HTTP-"Client" (Client) ist ein Programm, das eine Verbindung zu einem Server herstellt, um eine oder mehrere HTTP-Anfragen zu senden. Ein HTTP-"Server" (Server) ist ein Programm, das Verbindungen akzeptiert, um HTTP-Anfragen durch das Senden von HTTP-Antworten zu bedienen.
Die Begriffe Client und Server beziehen sich nur auf die Rollen, die diese Programme für eine bestimmte Verbindung ausführen. Dasselbe Programm kann bei einigen Verbindungen als Client und bei anderen als Server fungieren.
HTTP ist als zustandsloses Protokoll (Stateless Protocol) definiert, was bedeutet, dass die Semantik jeder Anfragenachricht isoliert verstanden werden kann und dass die Beziehung zwischen Verbindungen und den darauf befindlichen Nachrichten keinen Einfluss auf die Interpretation dieser Nachrichten hat. Zum Beispiel kann eine CONNECT-Anfrage (Abschnitt 9.3.6) oder eine Anfrage mit dem Upgrade-Header-Feld (Abschnitt 7.8) jederzeit auftreten, nicht nur in der ersten Nachricht auf einer Verbindung. Viele Implementierungen hängen vom zustandslosen Design von HTTP ab, um Proxy-Verbindungen wiederzuverwenden oder Anfragen dynamisch über mehrere Server zu verteilen.
Infolgedessen darf ein Server nicht (MUST NOT) annehmen, dass zwei Anfragen auf derselben Verbindung vom selben Benutzeragenten stammen, es sei denn, die Verbindung ist gesichert und spezifisch für diesen Agenten. Einige nicht standardmäßige HTTP-Erweiterungen (z. B. [RFC4559]) sind dafür bekannt, diese Anforderung zu verletzen, was zu Sicherheits- und Interoperabilitätsproblemen führt.
3.4. Messages (Nachrichten)
HTTP ist ein zustandsloses Anfrage/Antwort-Protokoll zum Austausch von "Nachrichten" (Messages) über eine Verbindung. Die Begriffe "Sender" (Sender) und "Empfänger" (Recipient) beziehen sich auf jede Implementierung, die eine gegebene Nachricht sendet bzw. empfängt.
Ein Client sendet Anfragen an einen Server in Form einer "Anfrage"-Nachricht (Request) mit einer Methode (Abschnitt 9) und einem Anfrageziel (Abschnitt 7.1). Die Anfrage kann auch Header-Felder (Abschnitt 6.3) für Anfrage-Modifikatoren, Client-Informationen und Repräsentationsmetadaten, Inhalt (Abschnitt 6.4), der zur Verarbeitung gemäß der Methode bestimmt ist, und Trailer-Felder (Abschnitt 6.5) enthalten, um während des Sendens des Inhalts gesammelte Informationen zu kommunizieren.
Ein Server antwortet auf die Anfrage eines Clients, indem er eine oder mehrere "Antwort"-Nachrichten (Response) sendet, die jeweils einen Statuscode (Abschnitt 15) enthalten. Die Antwort kann auch Header-Felder für Server-Informationen, Ressourcen-Metadaten und Repräsentationsmetadaten, Inhalt, der gemäß dem Statuscode zu interpretieren ist, und Trailer-Felder enthalten, um während des Sendens des Inhalts gesammelte Informationen zu kommunizieren.
3.5. User Agents (Benutzeragenten)
Der Begriff "Benutzeragent" (User Agent) bezieht sich auf eines der verschiedenen Client-Programme, die eine Anfrage initiieren.
Die vertrauteste Form des Benutzeragenten ist der Allzweck-Webbrowser, aber das ist nur ein kleiner Prozentsatz der Implementierungen. Andere häufige Benutzeragenten umfassen Spider (Web-Durchquerungsroboter), Befehlszeilentools, Werbetafeln, Haushaltsgeräte, Waagen, Glühbirnen, Firmware-Update-Skripte, mobile Apps und Kommunikationsgeräte in einer Vielzahl von Formen und Größen.
Ein Benutzeragent zu sein bedeutet nicht, dass zum Zeitpunkt einer Anfrage ein menschlicher Benutzer direkt mit dem Software-Agenten interagiert. In vielen Fällen ist ein Benutzeragent installiert oder so konfiguriert, dass er im Hintergrund läuft und seine Ergebnisse zur späteren Überprüfung speichert (oder nur eine Teilmenge dieser Ergebnisse speichert, die interessant oder fehlerhaft sein könnten). Spider erhalten beispielsweise normalerweise einen Start-URI und sind so konfiguriert, dass sie bei der Durchquerung des Webs als Hypertextgraph einem bestimmten Verhalten folgen.
Viele Benutzeragenten können ihrem Benutzer keine interaktiven Vorschläge machen oder keine angemessenen Warnungen für Sicherheits- oder Datenschutzbedenken bereitstellen, oder sie entscheiden sich dagegen. In den wenigen Fällen, in denen diese Spezifikation die Meldung von Fehlern an den Benutzer erfordert, ist es akzeptabel, dass eine solche Meldung nur in einer Fehlerkonsole oder Protokolldatei beobachtbar ist. Ebenso können Anforderungen, dass eine automatisierte Aktion vor dem Fortfahren vom Benutzer bestätigt werden muss, durch vorab konfigurierte Auswahlmöglichkeiten, Laufzeitoptionen oder einfaches Vermeiden der unsicheren Aktion erfüllt werden; Bestätigung impliziert keine spezifische Benutzeroberfläche oder Unterbrechung der normalen Verarbeitung, wenn der Benutzer diese Wahl bereits getroffen hat.
3.6. Origin Server (Ursprungsserver)
Der Begriff "Ursprungsserver" (Origin Server) bezieht sich auf ein Programm, das autoritative Antworten (Authoritative Responses) für eine gegebene Zielressource liefern kann.
Die vertrauteste Form von Ursprungsservern sind große öffentliche Websites. Wie jedoch Benutzeragenten mit Browsern gleichgesetzt werden, ist es leicht, irregeführt zu werden zu denken, dass alle Ursprungsserver gleich sind. Häufige Ursprungsserver umfassen auch Hausautomationseinheiten, konfigurierbare Netzwerkkomponenten, Büromaschinen, autonome Roboter, Nachrichtenfeeds, Verkehrskameras, Echtzeit-Werbungsauswähler und Video-on-Demand-Plattformen.
Die meiste HTTP-Kommunikation besteht aus einer Abrufanfrage (GET) für eine Repräsentation einer durch einen URI identifizierten Ressource. Im einfachsten Fall könnte dies über eine einzelne bidirektionale Verbindung (===) zwischen dem Benutzeragenten (UA) und dem Ursprungsserver (O) erreicht werden.
request >
UA ======================================= O
< response
Abbildung 1
3.7. Intermediaries (Vermittler)
HTTP ermöglicht die Verwendung von Vermittlern (Intermediaries), um Anfragen durch eine Kette von Verbindungen zu erfüllen. Es gibt drei häufige Formen von HTTP-"Vermittlern": Proxy, Gateway und Tunnel. In einigen Fällen kann ein einzelner Vermittler als Ursprungsserver, Proxy, Gateway oder Tunnel fungieren und das Verhalten basierend auf der Natur jeder Anfrage wechseln.
> > > >
UA =========== A =========== B =========== C =========== O
< < < <
Abbildung 2
Die obige Abbildung zeigt drei Vermittler (A, B und C) zwischen dem Benutzeragenten und dem Ursprungsserver. Eine Anfrage- oder Antwortnachricht, die die gesamte Kette durchläuft, passiert vier separate Verbindungen. Einige HTTP-Kommunikationsoptionen können nur für die Verbindung mit dem nächsten Nicht-Tunnel-Nachbarn gelten, nur für die Endpunkte der Kette oder für alle Verbindungen entlang der Kette. Obwohl das Diagramm linear ist, kann jeder Teilnehmer an mehreren gleichzeitigen Kommunikationen beteiligt sein. Zum Beispiel könnte B Anfragen von vielen anderen Clients als A empfangen und/oder Anfragen an andere Server als C weiterleiten, während er gleichzeitig die Anfrage von A bearbeitet. Ebenso können spätere Anfragen über einen anderen Pfad von Verbindungen gesendet werden, oft basierend auf dynamischer Konfiguration für Lastverteilung.
Die Begriffe "upstream" (aufwärts) und "downstream" (abwärts) werden verwendet, um Richtungsanforderungen in Bezug auf den Nachrichtenfluss zu beschreiben: Alle Nachrichten fließen von upstream nach downstream. Die Begriffe "inbound" (eingehend) und "outbound" (ausgehend) werden verwendet, um Richtungsanforderungen in Bezug auf die Anfrageroute zu beschreiben: inbound bedeutet "zum Ursprungsserver hin", während outbound "zum Benutzeragenten hin" bedeutet.
Ein "Proxy" (Proxy) ist ein Nachrichten-Weiterleitungsagent, der vom Client gewählt wird, normalerweise über lokale Konfigurationsregeln, um Anfragen für bestimmte Typen von absoluten URIs zu empfangen und zu versuchen, diese Anfragen über Übersetzung durch die HTTP-Schnittstelle zu erfüllen. Einige Übersetzungen sind minimal, wie bei Proxy-Anfragen für "http"-URIs, während andere Anfragen eine Übersetzung zu und von völlig unterschiedlichen Anwendungsschichtprotokollen erfordern können. Proxies werden häufig verwendet, um die HTTP-Anfragen einer Organisation durch einen gemeinsamen Vermittler für Sicherheitsdienste, Annotationsdienste oder gemeinsames Caching zu gruppieren. Einige Proxies sind so konzipiert, dass sie Transformationen auf ausgewählte Nachrichten oder Inhalte anwenden, während sie weitergeleitet werden, wie in Abschnitt 7.7 beschrieben.
Ein "Gateway" (Gateway) (auch bekannt als "Reverse Proxy") ist ein Vermittler, der als Ursprungsserver für die ausgehende Verbindung fungiert, aber empfangene Anfragen übersetzt und sie eingehend an einen oder mehrere andere Server weiterleitet. Gateways werden häufig verwendet, um Legacy- oder nicht vertrauenswürdige Informationsdienste zu kapseln, die Serverleistung durch "Accelerator"-Caching zu verbessern und die Partitionierung oder Lastverteilung von HTTP-Diensten über mehrere Maschinen zu ermöglichen.
Alle HTTP-Anforderungen, die für einen Ursprungsserver gelten, gelten auch für die ausgehende Kommunikation eines Gateways. Ein Gateway kommuniziert mit eingehenden Servern unter Verwendung eines beliebigen Protokolls, einschließlich privater Erweiterungen zu HTTP, die außerhalb des Geltungsbereichs dieser Spezifikation liegen. Ein HTTP-to-HTTP-Gateway, das mit Drittanbieter-HTTP-Servern interoperieren möchte, muss jedoch den Benutzeragenten-Anforderungen auf der eingehenden Verbindung des Gateways entsprechen.
Ein "Tunnel" (Tunnel) fungiert als blindes Relais zwischen zwei Verbindungen, ohne die Nachrichten zu ändern. Sobald er aktiv ist, wird ein Tunnel nicht als Partei der HTTP-Kommunikation betrachtet, obwohl der Tunnel möglicherweise durch eine HTTP-Anfrage initiiert wurde. Ein Tunnel hört auf zu existieren, wenn beide Enden der weitergeleiteten Verbindung geschlossen sind. Tunnel werden verwendet, um eine virtuelle Verbindung durch einen Vermittler zu erweitern, z. B. wenn Transport Layer Security (TLS, [TLS13]) verwendet wird, um vertrauliche Kommunikation durch einen gemeinsamen Firewall-Proxy einzurichten.
Die obigen Kategorien für Vermittler betrachten nur diejenigen, die als Teilnehmer an der HTTP-Kommunikation fungieren. Es gibt auch Vermittler, die auf niedrigeren Schichten des Netzwerkprotokollstacks agieren können und HTTP-Verkehr ohne das Wissen oder die Erlaubnis der Nachrichtensender filtern oder umleiten. Netzwerkvermittler sind (auf Protokollebene) nicht von einem On-Path-Angreifer zu unterscheiden und führen oft zu Sicherheitslücken oder Interoperabilitätsproblemen, indem sie fälschlicherweise die HTTP-Semantik verletzen.
Zum Beispiel unterscheidet sich ein "Interception Proxy" [RFC3040] (auch allgemein als "Transparent Proxy" [RFC1919] bekannt) von einem HTTP-Proxy, weil er nicht vom Client gewählt wird. Stattdessen filtert oder leitet ein Interception Proxy ausgehende TCP-Port-80-Pakete um (und gelegentlich anderen gemeinsamen Portverkehr). Interception Proxies werden häufig an öffentlichen Netzwerkzugangspunkten gefunden, als Mittel zur Durchsetzung von Kontoabonnements vor der Erlaubnis zur Nutzung nicht lokaler Internetdienste, und innerhalb von Unternehmens-Firewalls zur Durchsetzung von Netzwerknutzungsrichtlinien.
3.8. Caches (Caches)
Ein "Cache" (Cache) ist ein lokaler Speicher vorheriger Antwortnachrichten und das Subsystem, das seine Nachrichtenspeicherung, -abruf und -löschung steuert. Ein Cache speichert cacheable Antworten, um die Antwortzeit und den Netzwerkbandbreitenverbrauch bei zukünftigen, gleichwertigen Anfragen zu reduzieren. Jeder Client oder Server kann (MAY) einen Cache verwenden, obwohl ein Cache nicht verwendet werden kann, während er als Tunnel fungiert.
Der Effekt eines Caches ist, dass die Anfrage/Antwort-Kette verkürzt wird, wenn einer der Teilnehmer entlang der Kette eine für diese Anfrage anwendbare gecachte Antwort hat. Das Folgende veranschaulicht die resultierende Kette, wenn B eine gecachte Kopie einer früheren Antwort von O (über C) für eine Anfrage hat, die nicht von UA oder A gecacht wurde.
> >
UA =========== A =========== B - - - - - - C - - - - - - O
< <
Abbildung 3
Eine Antwort ist "cacheable" (cachebar), wenn ein Cache eine Kopie der Antwortnachricht zur Verwendung bei der Beantwortung nachfolgender Anfragen speichern darf. Selbst wenn eine Antwort cachebar ist, können zusätzliche Einschränkungen vom Client oder vom Ursprungsserver darüber platziert werden, wann diese gecachte Antwort für eine bestimmte Anfrage verwendet werden kann. HTTP-Anforderungen für Cache-Verhalten und cacheable Antworten sind in [CACHING] definiert.
Es gibt eine große Vielfalt von Architekturen und Konfigurationen von Caches, die im World Wide Web und innerhalb großer Organisationen eingesetzt werden. Dazu gehören nationale Hierarchien von Proxy-Caches zur Einsparung von Bandbreite und Reduzierung der Latenz, Content Delivery Networks, die Gateway-Caching verwenden, um die regionale und globale Verteilung beliebter Sites zu optimieren, kollaborative Systeme, die Cache-Einträge senden oder multicasten, Archive von vorab abgerufenen Cache-Einträgen zur Verwendung in Offline- oder Hochlatenz-Umgebungen usw.
3.9. Example Message Exchange (Beispiel-Nachrichtenaustausch)
Das folgende Beispiel veranschaulicht einen typischen HTTP/1.1-Nachrichtenaustausch für eine GET-Anfrage (Abschnitt 9.3.1) auf den URI http://www.example.com/hello.txt:
Client-Anfrage:
GET /hello.txt HTTP/1.1
User-Agent: curl/7.64.1
Host: www.example.com
Accept-Language: en, mi
Server-Antwort:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
Hello World! My content includes a trailing CRLF.