Zum Hauptinhalt springen

2. Architecture (Architektur)

HTTP wurde als zustandsloses Kommunikationsprotokoll auf Anwendungsebene entwickelt, das für viele Aufgaben über seine Verwendung für Hypertext hinaus genutzt werden kann, wie z.B. für Namensserver und verteilte Objektverwaltungssysteme, durch Erweiterung seiner Anfragemethoden, Fehlercodes und Header.

2.1. Client/Server Messaging (Client/Server-Nachrichtenaustausch)​

HTTP ist ein zustandsloses Anfrage/Antwort-Protokoll. Ein Client sendet eine Anfrage in Form einer Anfragenachricht an einen Server. Der Server antwortet mit einer Antwortnachricht.

Die Terminologie "Client" und "Server" bezieht sich nur auf die Rollen, die diese Programme für eine bestimmte Verbindung übernehmen. Dasselbe Programm kann bei einigen Verbindungen als Client und bei anderen als Server fungieren.

2.2. Implementation Diversity (Implementierungsvielfalt)​

HTTP ist so konzipiert, dass es die Implementierungsdetails seiner Teilnehmer verbirgt. Daher kann HTTP mit vielen verschiedenen Transport-Protokollen niedrigerer Ebenen verwendet werden.

2.3. Intermediaries (Vermittler)​

HTTP-Vermittler sind Komponenten, die zwischen Client und Server liegen und als Nachrichtenübertragungsagenten fungieren.

Es gibt drei gängige Arten von HTTP-Vermittlern:

Proxy (Proxy)​

Ein Proxy ist ein vom Client ausgewählter Nachrichtenübertragungsagent, normalerweise durch lokale Konfiguration, um Anfragen für bestimmte Arten von absoluten URIs zu empfangen und zu versuchen, diese Anfragen durch Übersetzung zu erfüllen, falls erforderlich.

Gateway (Gateway)​

Ein Gateway (auch als Reverse-Proxy bekannt) ist ein Nachrichtenübertragungsagent, der als Ursprungsserver für die eingehende Anfrage fungiert, aber empfangene Anfragen übersetzt und an einen anderen Server (oder Server) weiterleitet.

Tunnel (Tunnel)​

Ein Tunnel fungiert als Relay zwischen zwei Verbindungen, ohne die Nachrichten zu ändern. Ein Tunnel hört auf zu existieren, wenn beide Enden der weitergeleiteten Verbindung geschlossen sind.

2.4. Caches (Caches)​

Ein Cache ist ein lokaler Speicher für Antwortnachrichten und das Subsystem, das deren Speicherung, Abruf und Löschung steuert. Ein Cache speichert Antworten auf Anfragen, um die Antwortzeit und den Netzwerkbandbreitenverbrauch bei zukünftigen äquivalenten Anfragen zu reduzieren.

2.5. Conformance and Error Handling (Konformität und Fehlerbehandlung)​

Das Schlüsselwort "MUST" (MUSS) oder die Begriffe "REQUIRED" (ERFORDERLICH) oder "SHALL" (MUSS) bedeuten, dass eine Definition eine absolute Anforderung der Spezifikation ist.

Das Schlüsselwort "MUST NOT" (DARF NICHT) oder der Ausdruck "SHALL NOT" (DARF NICHT) bedeuten, dass eine Definition ein absolutes Verbot der Spezifikation ist.

Das Schlüsselwort "SHOULD" (SOLLTE) oder das Adjektiv "RECOMMENDED" (EMPFOHLEN) bedeuten, dass es unter bestimmten Umständen triftige Gründe geben kann, ein bestimmtes Element zu ignorieren, aber alle Implikationen müssen verstanden und sorgfältig abgewogen werden, bevor ein anderer Kurs gewählt wird.

Das Schlüsselwort "SHOULD NOT" (SOLLTE NICHT) oder der Ausdruck "NOT RECOMMENDED" (NICHT EMPFOHLEN) bedeuten, dass unter bestimmten Umständen triftige Gründe existieren können, wenn das bestimmte Verhalten akzeptabel oder sogar nützlich ist.

Das Schlüsselwort "MAY" (KANN) oder das Adjektiv "OPTIONAL" (OPTIONAL) bedeuten, dass ein Element wirklich optional ist.

2.6. Protocol Versioning (Protokollversionierung)​

HTTP verwendet ein Versionsnummerierungsschema "<major>.<minor>", um Protokollversionen anzugeben. Dieses Dokument definiert HTTP/1.1.

2.7. Uniform Resource Identifiers (Einheitliche Ressourcenkennungen)​

Uniform Resource Identifiers (URI) [RFC3986] werden in HTTP verwendet, um Ressourcen zu identifizieren. URI-Referenzen werden verwendet, um Anfragen zu zielen, Umleitungen anzuzeigen und Beziehungen zu definieren.

URI-reference = <URI-reference, siehe [RFC3986], Section 4.1>
absolute-URI  = <absolute-URI, siehe [RFC3986], Section 4.3>
relative-part = <relative-part, siehe [RFC3986], Section 4.2>
authority     = <authority, siehe [RFC3986], Section 3.2>
uri-host      = <host, siehe [RFC3986], Section 3.2.2>
port          = <port, siehe [RFC3986], Section 3.2.3>
path-abempty  = <path-abempty, siehe [RFC3986], Section 3.3>
segment       = <segment, siehe [RFC3986], Section 3.3>
query         = <query, siehe [RFC3986], Section 3.4>

2.7.1. http URI Scheme (http-URI-Schema)​

Das "http"-Schema wird verwendet, um Netzwerkressourcen über das HTTP-Protokoll zu lokalisieren.

http-URI = "http://" authority path-abempty [ "?" query ]
           [ "#" fragment ]

2.7.2. https URI Scheme (https-URI-Schema)​

Das "https"-Schema wird verwendet, um Netzwerkressourcen über das HTTP-Protokoll über eine gesicherte Verbindung zu lokalisieren.

https-URI = "https://" authority path-abempty [ "?" query ]
            [ "#" fragment ]

2.7.3. http and https URI Normalization and Comparison (HTTP- und HTTPS-URI-Normalisierung und -Vergleich)​

HTTP- und HTTPS-URIs werden auf die gleiche Weise wie alle anderen URIs verglichen.

Letztes Update am