Zum Hauptinhalt springen

4. Antworten auf eine Bereichsanforderung (Responses to a Range Request)

4.1 206 Partial Content​

Der Statuscode 206 (Partial Content) zeigt an, dass der Server eine Bereichsanforderung für die Zielressource erfolgreich erfüllt, indem er einen oder mehrere Teile der ausgewählten Repräsentation überträgt, die den im Header-Feld Range der Anfrage (Abschnitt 3.1) gefundenen erfüllbaren Bereichen entsprechen.

Wenn ein einzelner Teil übertragen wird, muss der Server, der die 206-Antwort erzeugt, ein Header-Feld Content-Range erzeugen, das beschreibt, welcher Bereich der ausgewählten Repräsentation eingeschlossen ist, sowie eine Nutzlast, die aus diesem Bereich besteht (MUST). Zum Beispiel:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

... 26012 bytes of partial image data ...

Wenn mehrere Teile übertragen werden, muss der Server, der die 206-Antwort erzeugt, eine "multipart/byteranges"-Nutzlast, wie in Anhang A definiert, sowie ein Header-Feld Content-Type erzeugen, das den Medientyp multipart/byteranges und seinen erforderlichen Parameter boundary enthält (MUST). Um Verwechslungen mit einteiligen Antworten zu vermeiden, darf ein Server im HTTP-Header-Bereich einer mehrteiligen Antwort kein Header-Feld Content-Range erzeugen (MUST NOT) (dieses Feld wird stattdessen in jedem Teil gesendet).

Innerhalb des Header-Bereichs jedes Body-Teils der Multipart-Nutzlast muss der Server ein Header-Feld Content-Range erzeugen, das dem in diesem Body-Teil eingeschlossenen Bereich entspricht (MUST). Wenn die ausgewählte Repräsentation in einer 200-(OK)-Antwort ein Header-Feld Content-Type gehabt hätte, sollte der Server dasselbe Content-Type-Feld im Header-Bereich jedes Body-Teils erzeugen (SHOULD). Zum Beispiel:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000

...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000

...the second range
--THIS_STRING_SEPARATES--

Wenn mehrere Bereiche angefordert werden, kann ein Server beliebige der Bereiche zusammenfassen, die sich überlappen oder die durch eine Lücke getrennt sind, die kleiner ist als der Aufwand für das Senden mehrerer Teile, unabhängig von der Reihenfolge, in der die entsprechenden byte-range-spec im empfangenen Header-Feld Range auftraten (MAY). Da der typische Aufwand zwischen den Teilen einer multipart/byteranges-Nutzlast etwa 80 Bytes beträgt (abhängig vom Medientyp der ausgewählten Repräsentation und von der Länge des gewählten Parameters boundary), kann es weniger effizient sein, viele kleine, nicht zusammenhängende Teile zu übertragen, als die gesamte ausgewählte Repräsentation zu übertragen.

Ein Server darf für eine Anforderung eines einzelnen Bereichs keine Multipart-Antwort erzeugen (MUST NOT), da ein Client, der nicht mehrere Teile anfordert, Multipart-Antworten möglicherweise nicht unterstützt. Ein Server kann jedoch eine multipart/byteranges-Nutzlast mit nur einem einzigen Body-Teil erzeugen, wenn mehrere Bereiche angefordert wurden und sich nur ein Bereich als erfüllbar erwies oder nach dem Zusammenfassen nur ein Bereich übrig blieb (MAY). Ein Client, der eine multipart/byteranges-Antwort nicht verarbeiten kann, darf keine Anfrage erzeugen, die mehrere Bereiche verlangt (MUST NOT).

Wenn eine Multipart-Antwortnutzlast erzeugt wird, sollte der Server die Teile in derselben Reihenfolge senden, in der die entsprechende byte-range-spec im empfangenen Header-Feld Range auftrat, mit Ausnahme der Bereiche, die als nicht erfüllbar erachtet oder mit anderen Bereichen zusammengefasst wurden (SHOULD). Ein Client, der eine Multipart-Antwort empfängt, muss das in jedem Body-Teil vorhandene Header-Feld Content-Range prüfen, um zu bestimmen, welcher Bereich in diesem Body-Teil enthalten ist (MUST); ein Client kann sich weder darauf verlassen, dieselben Bereiche zu empfangen, die er angefordert hat, noch auf dieselbe Reihenfolge, die er angefordert hat.

Wenn eine 206-Antwort erzeugt wird, muss der Server zusätzlich zu den oben geforderten Feldern die folgenden Header-Felder erzeugen, sofern das Feld in einer 200-(OK)-Antwort auf dieselbe Anfrage gesendet worden wäre: Date, Cache-Control, ETag, Expires, Content-Location und Vary (MUST).

Wenn eine 206-Antwort als Antwort auf eine Anfrage mit einem Header-Feld If-Range erzeugt wird, sollte der Absender über die oben geforderten Felder hinaus keine weiteren Repräsentations-Header-Felder erzeugen, da davon ausgegangen wird, dass der Client bereits über eine frühere Antwort mit diesen Header-Feldern verfügt (SHOULD NOT). Andernfalls muss der Absender alle Repräsentations-Header-Felder erzeugen, die in einer 200-(OK)-Antwort auf dieselbe Anfrage gesendet worden wären (MUST).

Eine 206-Antwort ist standardmäßig cachefähig; d. h. sofern nichts anderes durch explizite Cache-Steuerung angegeben wird (siehe Abschnitt 4.2.2 von [RFC7234]).

4.2 Content-Range​

Das Header-Feld "Content-Range" wird in einer einteiligen 206-(Partial-Content)-Antwort gesendet, um den Teilbereich der ausgewählten Repräsentation anzugeben, der als Nachrichtennutzlast eingeschlossen ist; es wird in jedem Teil einer mehrteiligen 206-Antwort gesendet, um den in jedem Body-Teil eingeschlossenen Bereich anzugeben; und es wird in 416-(Range-Not-Satisfiable)-Antworten gesendet, um Informationen über die ausgewählte Repräsentation bereitzustellen.

Content-Range = byte-content-range / other-content-range

byte-content-range = bytes-unit SP
                     ( byte-range-resp / unsatisfied-range )

byte-range-resp = byte-range "/" ( complete-length / "*" )
byte-range = first-byte-pos "-" last-byte-pos
unsatisfied-range = "*/" complete-length

complete-length = 1*DIGIT

other-content-range = other-range-unit SP other-range-resp
other-range-resp = *CHAR

Wenn eine 206-(Partial-Content)-Antwort ein Header-Feld Content-Range mit einer Bereichseinheit enthält (Abschnitt 2), die der Empfänger nicht versteht, darf der Empfänger nicht versuchen, sie mit einer gespeicherten Repräsentation wieder zusammenzusetzen (MUST NOT). Ein Proxy, der eine solche Nachricht empfängt, sollte sie weiterleiten (SHOULD).

Bei Byte-Bereichen sollte ein Absender die vollständige Länge der Repräsentation angeben, aus der der Bereich extrahiert wurde, es sei denn, die vollständige Länge ist unbekannt oder schwer zu bestimmen (SHOULD). Ein Sternchen ("*") anstelle der complete-length zeigt an, dass die Länge der Repräsentation zum Zeitpunkt der Erzeugung des Header-Felds unbekannt war.

Das folgende Beispiel veranschaulicht den Fall, dass die vollständige Länge der ausgewählten Repräsentation dem Absender mit 1234 Bytes bekannt ist:

Content-Range: bytes 42-1233/1234

und dieses zweite Beispiel veranschaulicht den Fall, dass die vollständige Länge unbekannt ist:

Content-Range: bytes 42-1233/*

Ein Content-Range-Feldwert ist ungültig, wenn er eine byte-range-resp enthält, deren Wert last-byte-pos kleiner als ihr Wert first-byte-pos ist, oder einen Wert complete-length, der kleiner oder gleich ihrem Wert last-byte-pos ist. Der Empfänger eines ungültigen Content-Range darf nicht versuchen, den empfangenen Inhalt mit einer gespeicherten Repräsentation wieder zusammenzusetzen (MUST NOT).

Ein Server, der eine 416-(Range-Not-Satisfiable)-Antwort auf eine Byte-Bereichsanforderung erzeugt, sollte ein Header-Feld Content-Range mit einem Wert unsatisfied-range senden, wie im folgenden Beispiel (SHOULD):

Content-Range: bytes */1234

Die complete-length in einer 416-Antwort gibt die aktuelle Länge der ausgewählten Repräsentation an.

Das Header-Feld Content-Range hat für Statuscodes keine Bedeutung, die seine Semantik nicht ausdrücklich beschreiben. In dieser Spezifikation beschreiben nur die Statuscodes 206 (Partial Content) und 416 (Range Not Satisfiable) eine Bedeutung für Content-Range.

Im Folgenden finden Sie Beispiele für Content-Range-Werte, bei denen die ausgewählte Repräsentation insgesamt 1234 Bytes enthält:

  • Die ersten 500 Bytes: Content-Range: bytes 0-499/1234

  • Die zweiten 500 Bytes: Content-Range: bytes 500-999/1234

  • Alles außer den ersten 500 Bytes: Content-Range: bytes 500-1233/1234

  • Die letzten 500 Bytes: Content-Range: bytes 734-1233/1234

4.3 Zusammenfassen von Bereichen (Combining Ranges)​

Eine Antwort überträgt möglicherweise nur einen Teilbereich einer Repräsentation, wenn die Verbindung vorzeitig geschlossen wurde oder wenn die Anfrage eine oder mehrere Range-Angaben verwendet hat. Nach mehreren solchen Übertragungen hat ein Client möglicherweise mehrere Bereiche derselben Repräsentation empfangen. Diese Bereiche können nur dann sicher zusammengefasst werden, wenn sie alle denselben starken Validator gemeinsam haben (Abschnitt 2.1 von [RFC7232]).

Ein Client, der mehrere Teilantworten auf GET-Anfragen für eine Zielressource empfangen hat, kann diese Antworten zu einem größeren zusammenhängenden Bereich zusammenfassen, wenn sie denselben starken Validator gemeinsam haben (MAY).

Wenn die jüngste Antwort eine unvollständige 200-(OK)-Antwort ist, werden die Header-Felder dieser Antwort für jede zusammengefasste Antwort verwendet und ersetzen die der übereinstimmenden gespeicherten Antworten.

Wenn die jüngste Antwort eine 206-(Partial-Content)-Antwort ist und mindestens eine der übereinstimmenden gespeicherten Antworten eine 200-(OK)-Antwort ist, bestehen die Header-Felder der zusammengefassten Antwort aus den Header-Feldern der jüngsten 200-Antwort. Wenn alle übereinstimmenden gespeicherten Antworten 206-Antworten sind, wird die gespeicherte Antwort mit den jüngsten Header-Feldern als Quelle der Header-Felder für die zusammengefasste Antwort verwendet, mit der Ausnahme, dass der Client andere in der neuen Antwort bereitgestellte Header-Felder (außer Content-Range) verwenden muss, um alle Vorkommen der entsprechenden Header-Felder in der gespeicherten Antwort zu ersetzen (MUST).

Der Nachrichtenkörper der zusammengefassten Antwort besteht aus der Vereinigung der Teilinhaltbereiche in der neuen Antwort und in jeder der ausgewählten Antworten. Wenn die Vereinigung den gesamten Bereich der Repräsentation umfasst, muss der Client die zusammengefasste Antwort so verarbeiten, als wäre sie eine vollständige 200-(OK)-Antwort, einschließlich eines Header-Felds Content-Length, das die vollständige Länge widerspiegelt (MUST). Andernfalls muss der Client die Menge zusammenhängender Bereiche als eines der folgenden verarbeiten (MUST): eine unvollständige 200-(OK)-Antwort, wenn die zusammengefasste Antwort ein Präfix der Repräsentation ist; eine einzelne 206-(Partial-Content)-Antwort mit einem multipart/byteranges-Körper; oder mehrere 206-(Partial-Content)-Antworten, die jeweils einen zusammenhängenden Bereich enthalten, der durch ein Header-Feld Content-Range angegeben wird.

4.4 416 Range Not Satisfiable​

Der Statuscode 416 (Range Not Satisfiable) zeigt an, dass keiner der Bereiche im Header-Feld Range der Anfrage (Abschnitt 3.1) den aktuellen Umfang der ausgewählten Ressource überlappt, oder dass die angeforderte Menge von Bereichen aufgrund ungültiger Bereiche oder einer übermäßigen Anforderung von kleinen oder überlappenden Bereichen zurückgewiesen wurde.

Bei Byte-Bereichen bedeutet das Fehlen einer Überlappung mit dem aktuellen Umfang, dass der first-byte-pos aller byte-range-spec-Werte größer war als die aktuelle Länge der ausgewählten Repräsentation. Wenn dieser Statuscode als Antwort auf eine Byte-Bereichsanforderung erzeugt wird, sollte der Absender ein Header-Feld Content-Range erzeugen, das die aktuelle Länge der ausgewählten Repräsentation angibt (Abschnitt 4.2) (SHOULD).

Zum Beispiel:

HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022

Hinweis: Da es Servern freisteht, Range zu ignorieren, werden viele Implementierungen einfach mit der gesamten ausgewählten Repräsentation in einer 200-(OK)-Antwort antworten. Das liegt zum Teil daran, dass die meisten Clients darauf vorbereitet sind, eine 200-(OK)-Antwort zu erhalten, um die Aufgabe abzuschließen (wenn auch weniger effizient), und zum Teil daran, dass Clients möglicherweise nicht aufhören, eine ungültige Teilbereichsanforderung zu stellen, bis sie eine vollständige Repräsentation empfangen haben. Daher können sich Clients nicht darauf verlassen, eine 416-(Range-Not-Satisfiable)-Antwort zu erhalten, selbst wenn sie am angemessensten wäre.