Zum Hauptinhalt springen

3. Bereichsanforderungen (Range Requests)

3.1 Range​

Das Header-Feld "Range" in einer GET-Anfrage ändert die Semantik der Methode dahingehend, dass nur die Übertragung eines oder mehrerer Teilbereiche der ausgewählten Repräsentationsdaten angefordert wird, anstatt der gesamten ausgewählten Repräsentationsdaten.

Range = byte-ranges-specifier / other-ranges-specifier
other-ranges-specifier = other-range-unit "=" other-range-set
other-range-set = 1*VCHAR

Ein Server kann das Header-Feld Range ignorieren (MAY). Ursprungsserver und Zwischenspeicher sollten jedoch Byte-Bereiche unterstützen, wenn dies möglich ist, da Range eine effiziente Wiederherstellung nach teilweise fehlgeschlagenen Übertragungen und den teilweisen Abruf großer Repräsentationen unterstützt. Ein Server muss ein Header-Feld Range ignorieren, das mit einer anderen Anfragemethode als GET empfangen wird (MUST).

Ein Ursprungsserver muss ein Header-Feld Range ignorieren, das eine Bereichseinheit enthält, die er nicht versteht (MUST). Ein Proxy kann ein Header-Feld Range verwerfen, das eine Bereichseinheit enthält, die er nicht versteht (MAY).

Ein Server, der Bereichsanforderungen unterstützt, kann ein Header-Feld Range ignorieren oder zurückweisen, das aus mehr als zwei überlappenden Bereichen besteht oder aus einer Menge vieler kleiner Bereiche, die nicht in aufsteigender Reihenfolge aufgeführt sind, da beides entweder auf einen fehlerhaften Client oder auf einen absichtlichen Denial-of-Service-Angriff (Abschnitt 6.1) hindeutet (MAY). Ein Client sollte nicht mehrere Bereiche anfordern, deren Verarbeitung und Übertragung von Natur aus weniger effizient ist als ein einzelner Bereich, der dieselben Daten umfasst (SHOULD NOT).

Ein Client, der mehrere Bereiche anfordert, sollte diese Bereiche in aufsteigender Reihenfolge auflisten (also in der Reihenfolge, in der sie in einer vollständigen Repräsentation üblicherweise empfangen würden), es sei denn, es besteht ein besonderer Bedarf, einen späteren Teil früher anzufordern (SHOULD). Beispielsweise kann ein Benutzeragent, der eine große Repräsentation mit einem internen Katalog von Teilen verarbeitet, spätere Teile zuerst anfordern müssen, insbesondere wenn die Repräsentation aus Seiten besteht, die in umgekehrter Reihenfolge gespeichert sind, und der Benutzeragent eine Seite nach der anderen übertragen möchte.

Das Header-Feld Range wird nach der Auswertung der in [RFC7232] definierten Vorbedingungs-Header-Felder ausgewertet, und nur dann, wenn das Ergebnis ohne das Header-Feld Range eine 200-(OK)-Antwort wäre. Mit anderen Worten: Range wird ignoriert, wenn eine bedingte GET-Anfrage zu einer 304-(Not-Modified)-Antwort führen würde.

Das Header-Feld If-Range (Abschnitt 3.2) kann als Vorbedingung für die Anwendung des Header-Felds Range verwendet werden.

Wenn alle Vorbedingungen zutreffen, der Server das Header-Feld Range für die Zielressource unterstützt und der bzw. die angegebenen Bereiche gültig und (wie in Abschnitt 2.1 definiert) erfüllbar sind, sollte der Server eine 206-(Partial-Content)-Antwort mit einer Nutzlast senden, die eine oder mehrere Teilrepräsentationen enthält, die den angeforderten erfüllbaren Bereichen entsprechen, wie in Abschnitt 4 definiert (SHOULD).

Wenn alle Vorbedingungen zutreffen, der Server das Header-Feld Range für die Zielressource unterstützt und der bzw. die angegebenen Bereiche ungültig oder nicht erfüllbar sind, sollte der Server eine 416-(Range-Not-Satisfiable)-Antwort senden (SHOULD).

3.2 If-Range​

Wenn ein Client eine teilweise Kopie einer Repräsentation besitzt und eine aktuelle Kopie der gesamten Repräsentation wünscht, kann er das Header-Feld Range zusammen mit einer bedingten GET-Anfrage verwenden (unter Verwendung von If-Unmodified-Since und/oder If-Match). Wenn die Vorbedingung jedoch fehlschlägt, weil die Repräsentation geändert wurde, müsste der Client anschließend eine zweite Anfrage stellen, um die gesamte aktuelle Repräsentation zu erhalten.

Das Header-Feld "If-Range" ermöglicht es einem Client, die zweite Anfrage "kurzzuschließen". Informell ausgedrückt lautet seine Bedeutung wie folgt: Wenn die Repräsentation unverändert ist, sende mir die Teile, die ich in Range anfordere; andernfalls sende mir die gesamte Repräsentation.

If-Range = entity-tag / HTTP-date

Ein Client darf kein Header-Feld If-Range in einer Anfrage erzeugen, die kein Header-Feld Range enthält (MUST NOT). Ein Server muss ein Header-Feld If-Range ignorieren, das in einer Anfrage empfangen wird, die kein Header-Feld Range enthält (MUST). Ein Ursprungsserver muss ein Header-Feld If-Range ignorieren, das in einer Anfrage für eine Zielressource empfangen wird, die keine Bereichsanforderungen unterstützt (MUST).

Ein Client darf kein Header-Feld If-Range erzeugen, das ein Entitäts-Tag (entity-tag) enthält, das als schwach (weak) gekennzeichnet ist (MUST NOT). Ein Client darf kein Header-Feld If-Range erzeugen, das ein HTTP-Datum enthält, es sei denn, der Client besitzt kein Entitäts-Tag für die entsprechende Repräsentation und das Datum ist ein starker Validator im Sinne der Definition in Abschnitt 2.2.2 von [RFC7232] (MUST NOT).

Ein Server, der eine If-Range-Vorbedingung auswertet, muss beim Vergleich von Entitäts-Tags die Funktion für den starken Vergleich verwenden (Abschnitt 2.3.2 von [RFC7232]) (MUST) und muss die Bedingung als falsch auswerten, wenn ein HTTP-Datum als Validator angegeben wird, das kein starker Validator im Sinne der Definition in Abschnitt 2.2.2 von [RFC7232] ist (MUST). Ein gültiges Entitäts-Tag lässt sich von einem gültigen HTTP-Datum unterscheiden, indem die ersten beiden Zeichen auf ein DQUOTE (doppeltes Anführungszeichen) geprüft werden.

Wenn der im Header-Feld If-Range angegebene Validator mit dem aktuellen Validator für die ausgewählte Repräsentation der Zielressource übereinstimmt, sollte der Server das Header-Feld Range wie angefordert verarbeiten (SHOULD). Wenn der Validator nicht übereinstimmt, muss der Server das Header-Feld Range ignorieren (MUST). Beachten Sie, dass sich dieser Vergleich durch exakte Übereinstimmung, auch wenn der Validator ein HTTP-Datum ist, von dem Vergleich "früher als oder gleich" unterscheidet, der bei der Auswertung einer If-Unmodified-Since-Bedingung verwendet wird.