Zusammenfassung

  • Ein Byteoffset beschreibt die Position eines Fragments, aber nicht die Version der Repräsentation, aus der es stammt.
  • Range und If-Range ergeben eine Verzweigung: starke Übereinstimmung lässt die Bereichsverarbeitung bestehen, Abweichung lässt den Server den Bereich ignorieren und das aktuelle Ganze senden.
  • Die Regel spart eine zweite Anfrage und verhindert Versionsmischung, ohne Bereichsunterstützung, Empfang, Speicherung, Inhaltsrichtigkeit oder Herkunft zu garantieren.

Die richtige Position konnte im falschen Objekt liegen

Eine Übertragung endet nach den ersten zwei Millionen Bytes. Der Client speichert sie und bittet später um alles ab Byte 2.000.000. Ist das Objekt unverändert, vermeidet er eine Wiederholung. Wurde das Archiv inzwischen neu gebaut oder eine andere Inhaltskodierung ausgewählt, zeigt derselbe Offset in eine andere Bytefolge. Der neue Rest kann fehlerfrei eintreffen und mit dem alten Anfang dennoch ein Objekt bilden, das der Server nie angeboten hat.

Die neue Verbindung erbte nicht automatisch die Identität der alten Darstellung. Range löste die räumliche Frage, nicht die zeitliche. Neben der Koordinate musste der Client eine begrenzte Evidenz mitführen, die seine gespeicherten Bytes an die derzeit ausgewählte Repräsentation band.

RFC 2068 standardisierte If-Range 1997 im ersten HTTP/1.1. Ein Client mit einer Teilkopie konnte einen Bereich mit einer gewöhnlichen Bedingung anfordern. Hatte sich die Entität geändert, scheiterte die Bedingung; für den vollständigen aktuellen Body brauchte der Client danach eine zweite Anfrage. If-Range kürzte diesen Weg ab: unverändert bedeutet fehlende Teile, verändert bedeutet die ganze neue Entität.

1999 übernahm RFC 2616 diese zwei Ergebnisse. Ein passender Entity-Tag führte zur Teilantwort 206 Partial Content. Ein abweichender Tag führte zur vollständigen Antwort 200 OK. Ein falsches Ergebnis verweigerte den Abruf nicht. Es entzog nur die Erlaubnis, eine alte Teilkopie wirtschaftlich zu ergänzen.

Eine Anfrage akzeptierte zwei Antwortformen

Die Felder konnten so aussehen:

Range: bytes=2000000-
If-Range: "revision-31"

Der Client verlangte nicht unter allen Umständen eine Teilantwort. Er akzeptierte sie nur, wenn "revision-31" die aktuelle Repräsentation weiterhin stark bezeichnete. Bei Abweichung ignorierte der Server Range und lieferte den vollständigen aktuellen Body. Der Client musste damit seine Teilkopie ersetzen, statt einen 200-Body anzuhängen.

Genau darin unterscheidet sich die Semantik von anderen Vorbedingungen. If-Match kann eine Operation verhindern und 412 Precondition Failed auslösen. If-None-Match kann bei GET zu 304 Not Modified ohne Body führen. If-Range entscheidet weder über Erlaubnis noch Existenz, sondern über die Form einer weiterhin nützlichen Antwort.

RFC 7233 trennte 2014 die Bereichssemantik ab. Ein Client darf If-Range nicht ohne Range erzeugen; ein Server ignoriert es ohne Bereich oder bei einem Ziel ohne Bereichsunterstützung. Stimmt der Validator überein, soll der Bereich verarbeitet werden. Stimmt er nicht überein, muss der Bereich ignoriert werden. Der Mechanismus spart den zweiten Abruf, erzeugt aber keine Fähigkeit, die der Server nicht hat.

Die heutige Zusammenführung in RFC 9110 hält die Reihenfolge fest. Bei GET mit beiden Feldern führt eine wahre Bedingung und ein anwendbarer Bereich zu 206. Andernfalls wird Range ignoriert und die Antwort ist 200. Früh erkennbare Fehler, Umleitungen und die normale Repräsentationsauswahl behalten Vorrang.

Teilstücke verlangten starke Gleichheit

HTTP kennt schwache Validatoren, weil semantische Austauschbarkeit oft genügt, obwohl Bytes abweichen. Für Cache-Aktualität kann eine anders formatierte, inhaltlich gleichwertige Seite akzeptabel sein. Für das Aneinanderschweißen von Bytebereichen ist sie es nicht. Eine Änderung am Anfang verschiebt alle folgenden Positionen.

RFC 7232 verlangt, dass ein starker Validator sich mit beobachtbaren Repräsentationsdaten ändert, und erlaubt ihn für Teilbereiche. Schwache Validatoren gehören zu Vergleichen ohne exakte Gleichheit. Deshalb darf ein Client keinen schwachen ETag in If-Range senden. Last-Modified ist nur zulässig, wenn kein Entity-Tag vorhanden ist und das Datum selbst die Anforderungen an einen starken Validator erfüllt.

Zeitstempel können zu grob sein. Zwei Änderungen in derselben Sekunde teilen möglicherweise ein Datum. If-Range vergleicht ein Datum exakt mit Last-Modified und nicht nach der „früher oder gleich“-Regel von If-Unmodified-Since. Schwache Zeitinformation schließt den Teilpfad; sie darf keine Kontinuität vortäuschen.

Auch ein starker ETag ist ein opaker Wert, nicht zwingend ein kryptografischer Hash. Seine Stärke ist die Zusage, ihn innerhalb des relevanten Geltungsbereichs dieses Ressourcenverlaufs nicht für beobachtbar verschiedene Bytes wiederzuverwenden. Er authentifiziert weder Herausgeber noch Inhalt und beweist keine Gleichheit mit einer anderen URL. Schon RFC 2616 warnte, dass gleiche Tags über verschiedene URIs keine Äquivalenz bedeuten.

Übereinstimmung war noch kein 206-Versprechen

Nach dem Vergleich prüft der Server weiter: Unterstützt er die Einheit, ist die Syntax gültig, überschneidet sich der Bereich mit der aktuellen Länge, ist die Anforderung vertretbar? Ein unterstützter, gültiger und erfüllbarer Bereich erhält normalerweise 206 Partial Content. Ein einzelner Teil trägt Content-Range; mehrere Teile verwenden multipart/byteranges. Liegt kein gewünschter Bereich in der aktuellen Repräsentation, kann 416 Range Not Satisfiable folgen.

Content-Range lokalisiert den gelieferten Body, beweist aber nicht die Version des gespeicherten Präfixes. Dafür ist der gemeinsame starke Validator zuständig. Dessen Übereinstimmung beweist wiederum nicht, dass der Client alles empfangen, richtig zusammengesetzt oder dauerhaft gespeichert hat.

Die Fehlerrichtungen sind ungleich. Eine unnötige Abweichung sendet das Ganze erneut: teuer, aber kohärent. Eine falsche Übereinstimmung kann geräuschlos ein Hybridobjekt erzeugen. Das Protokoll bevorzugt sichtbare Mehrkosten gegenüber unsichtbarer Vermischung.

Der Cache wurde zum Verwahrer der Fragmente

Ein Cache kann ein unvollständiges 200, ein 206 oder mehrere getrennte Bereiche halten. Beim Zusammenfügen übernimmt er Herkunftsverantwortung. RFC 7234 erlaubt unvollständige Speicherung nur für Caches, die Range und Content-Range verstehen. Bereiche dürfen nur unter demselben starken Validator kombiniert werden.

Lückenlose Koordinaten genügen nicht. Anfang vom Montag, Mitte vom Dienstag und Ende vom Mittwoch können die volle Länge ergeben, ohne eine gemeinsame Version zu bilden. Der Cache muss beim Kombinieren auch Metadaten aktualisieren und darf Unvollständiges nicht als vollständige 200-Antwort ausgeben.

RFC 9111 bewahrt diese Grenze. Ein Cache darf eine unvollständige Antwort mit späteren Bereichen vervollständigen, sie aber erst danach als vollständig wiederverwenden. Teilinhalt muss als 206 gekennzeichnet bleiben. If-Range speichert und montiert nichts; es liefert eine Versionsbedingung für die Antwortverzweigung.

Eine prüfbare Spur enthält Ziel, Auswahlfelder, Range, alten und aktuellen Validator, Vergleichsart, Status, Content-Range und Hash des montierten Objekts. Der Server kann seine Sendeseite belegen. Client oder Cache können Empfang und Zusammenbau belegen. Kein einzelnes Feld deckt die ganze Kette ab.

Kontinuität ohne weltweites Versionsregister

HTTP führte weder eine zentrale Nummerierung aller Dateiversionen noch eine Sperre für unterbrochene Clients ein. Die Origin erzeugte den Validator. Der Client verwahrte ihn mit dem Fragment. Der Server verglich den aktuellen Zustand. Der Cache verantwortete seine Teile. Die Entscheidung blieb bei den Akteuren mit der jeweiligen Evidenz.

Die gemeinsame Frage war klein: Darf der neue Bereich noch Teil der Repräsentation sein, die ich besitze? Ein Nein entzog die Bandbreitenersparnis, nicht den Zugriff auf die Gegenwart. Gerade diese Begrenzung machte Wiederaufnahme interoperabel, ohne eine Transfersitzung zur Autorität über die Ressource zu erheben.

Die RFCs definieren diese Semantik, nicht das Verhalten heutiger Produkte. Sie beweisen weder die Stärke eines Live-ETags noch korrekte Behandlung durch einen Vermittler, Bereichsunterstützung oder erfolgreiche Speicherung. Dafür braucht es Mitschnitte, Auswahlparameter, Validatorhistorie, Fragment-Hashes und den Montagebericht.