Zum Hauptinhalt springen

6. Connection Management (Verbindungsmanagement)

Die HTTP-Nachrichtenübertragung ist unabhängig von den zugrunde liegenden Transport- oder Sitzungsschicht-Verbindungsprotokollen. HTTP setzt nur einen zuverlässigen Transport voraus, der eine geordnete Zustellung von Anfragen und Antworten bieten kann.

6.1. Connection​

Der Connection-Header ermöglicht es dem Absender, gewünschte Steueroptionen für die aktuelle Verbindung anzugeben.

Connection        = 1#connection-option
connection-option = token

6.2. Establishment (Einrichtung)​

Der Client ist für die Einrichtung einer Verbindung zum Server verantwortlich. HTTP hat keine Anforderungen an das Nachrichtenframing zur Einrichtung oder Identifizierung der Verbindung selbst.

6.3. Persistence (Persistenz)​

HTTP/1.1 verwendet standardmäßig "persistente Verbindungen" (persistent connections), die es ermöglichen, mehrere Anfragen und Antworten über eine einzelne Verbindung zu senden. HTTP-Implementierungen SOLLTEN persistente Verbindungen unterstützen.

6.3.1. Retrying Requests (Wiederholung von Anfragen)​

Beim automatischen Wiederholen einer Anfrage kann die Verbindung während der Übertragung der Anfragenachricht (oder während des Wartens auf die Antwortnachricht) fehlschlagen. Ein Client SOLLTE eine Anfrage nicht automatisch wiederholen, es sei denn, er kann bestätigen, dass die Anfrage idempotent ist ([RFC7231], [Section 4.2.2]) oder er erhält eine Nachricht vom Ursprungsserver, die anzeigt, dass der Server die Anfrage vor dem Verbindungsfehler nicht verarbeitet hat.

6.3.2. Pipelining (Pipelining)​

Ein Client, der persistente Verbindungen unterstützt, KANN Anfragen "pipelinen" (d.h. mehrere Anfragen senden, ohne auf jede Antwort zu warten). Ein Server MUSS seine Antworten auf diese gepipelineten Anfragen in der gleichen Reihenfolge senden, in der die Anfragen empfangen wurden.

6.4. Concurrency (Nebenläufigkeit)​

Ein Client SOLLTE die Anzahl gleichzeitiger Verbindungen, die er zu einem Server aufbaut, begrenzen.

6.5. Failures and Timeouts (Fehler und Timeouts)​

Server haben normalerweise einen Timeout-Wert, nach dem sie eine inaktive Verbindung nicht mehr aufrechterhalten. Proxy-Server können kürzere Timeout-Werte verwenden, um Ressourcen zu schonen.

6.6. Tear-down (Abbau)​

Der Connection-Header (Section 6.1) bietet eine "close"-Verbindungsoption, die der Absender verwendet, um zu signalisieren, dass die Verbindung nach Abschluss der aktuellen Anfrage/Antwort geschlossen wird.

6.6.1. Retrying Requests (Wiederholung von Anfragen)​

Ein Client SOLLTE eine idempotente Anfrage wiederholen, wenn die Verbindung nach dem Senden der Anfrage geschlossen wird (selbst wenn der Client zuvor Anfragen über diese Verbindung gesendet hatte).

6.6.2. Closure (Schließung)​

Wenn ein Server ein sofortiges Schließen einer TCP-Verbindung durchführt, besteht ein erhebliches Risiko, dass der Client die letzte HTTP-Antwort nicht lesen kann.

6.7. Upgrade (Upgrade)​

Der Upgrade-Header bietet einen einfachen Mechanismus für den Übergang von HTTP/1.1 zu anderen inkompatiblen Protokollen.

Upgrade          = 1#protocol
protocol         = protocol-name ["/" protocol-version]
protocol-name    = token
protocol-version = token

Ein Server KANN das Protokoll wechseln, indem er eine 101 (Switching Protocols, Protokollwechsel)-Antwort sendet.

Letztes Update am