Zusammenfassung

  • HTTP 206 bestätigt die erfolgreiche Übertragung deklarierter Bereiche einer ausgewählten Repräsentation; allein beweist es nicht, dass getrennt abgerufene Bereiche ein vollständiges Objekt bilden.
  • Fortgesetzte Übertragungen und Cache-Zusammenführungen benötigen einen gemeinsamen starken Validator, eine exakte Intervallabdeckung und eine abschließende Prüfung der gesamten Repräsentation.
  • Content-Length misst bei einer 206-Antwort gewöhnlich deren Nachrichteninhalt, während Content-Range die Position und die Gesamtlänge der ausgewählten Repräsentation angibt.
  • Ein Prüfprotokoll für die Bereichszusammensetzung muss die Identität der Repräsentation und jedes akzeptierte Intervall bewahren, statt eine vollständige Bytezahl als ausreichenden Beweis zu behandeln.

Man stelle sich den Download eines Routing-Datenarchivs aus einem Objektspeicher vor. Die Verbindung bricht auf halber Strecke ab, und der Client fordert die fehlenden Bytes nach. Zwischen den Anfragen ersetzt der Ursprung den Snapshot durch einen neueren Export gleicher nomineller Größe. Beide Anfragen liefern 206, alle angeforderten Intervalle treffen ein, und der Zähler erreicht den erwarteten Wert. Trotzdem besteht die rekonstruierte Datei aus dem Anfang einer Repräsentation und dem Ende einer anderen, weil kein starker Validator die Versuche verbunden hat.

Dies ist ein hypothetischer Betriebsfehler, kein Vorwurf gegen einen Speicheranbieter. HTTP stellt die Mittel zu seiner Vermeidung bereit. Der Fehler liegt darin, einer Teilantwort mehr Beweiskraft zuzuschreiben, als ihre Semantik trägt.

Ein erfolgreicher Bereich hat eine begrenzte Aussage

RFC 9110 definiert 206 Partial Content als erfolgreiche Erfüllung einer Bereichsanfrage durch Übertragung eines oder mehrerer Teile der ausgewählten Repräsentation. Der Server erklärt, die genannten Intervalle geliefert zu haben; er erklärt nicht, dass der Client nun die vollständige Repräsentation besitzt.

Der Empfänger muss Content-Type und jedes Content-Range prüfen, um Inhalt und weiteren Bedarf zu bestimmen. Bei einem einzelnen Bereich bezeichnet Content-Range die inklusiven Grenzen und meist die Gesamtlänge. Content-Length zählt dagegen die Oktette im aktuellen 206-Nachrichteninhalt. Wer beides verwechselt, macht aus einer korrekten Teilantwort ein falsches Vollständigkeitssignal.

Mehrteilige Antworten erhöhen die Buchführungspflicht: Bereiche können in anderer Reihenfolge eintreffen, zusammengelegt werden oder bei Nichterfüllbarkeit fehlen. Die Abdeckung ist aus den tatsächlich gelieferten Intervallen zu berechnen, nicht aus Anfragereihenfolge, Antwortzahl oder Fortschrittsbalken.

Kontinuität gehört zur Repräsentation, nicht zur URL

Eine gleichbleibende URL bedeutet nicht, dass die ausgewählten Bytes unverändert blieben. Inhaltsaushandlung, Deployment, Erzeugungszeit oder ein Ursprungsupdate können die Repräsentation unter demselben URI verändern. Sicheres Fortsetzen verlangt den Nachweis, dass alte und neue Intervalle derselben Version angehören.

If-Range schützt diese Grenze. Der Client sendet die Bereichsanfrage mit einem Validator. Stimmt er noch, kann der Server den Teil liefern; stimmt er nicht, ignoriert der Server Range und sendet die vollständige neue Repräsentation. RFC 9110 untersagt schwache Entity-Tags in If-Range, weil die Kombination auf Byteebene einen Validator braucht, der geeignete Versionen sicher unterscheidet.

Eine 200-Antwort nach If-Range ist daher kein ineffizienter Fehler, der wieder zu 206 gezwungen werden sollte. Sie beweist, dass die alte Teilkopie nicht mehr sicher ergänzt werden kann. Der Client muss den alten Montagezustand verwerfen und die neue vollständige Repräsentation übernehmen.

Caches übernehmen dieselbe Pflicht

RFC 9111 erlaubt einem Cache, unvollständige Antworten später durch Bereichsübertragungen zu ergänzen. Zusammenführen darf er sie nur, wenn sie denselben starken Validator tragen und die Regeln für Teilinhalte eingehalten werden.

Trefferquote und gespeicherte Bytezahl genügen deshalb nicht. Nötig sind Cache-Schlüssel und Aushandlungsfelder, Validator jedes Intervalls, Header-Aktualisierungen und der Frische- oder Revalidierungszustand der zusammengesetzten Antwort. Downloadmanager, Spiegel und Speicher-Gateways haben dasselbe Beweisproblem, sobald sie Fragmente speichern.

Prüfen Sie die Integrität auf der richtigen Ebene

RFC 9530 trennt zwei Geltungsbereiche. Content-Digest wird über den Inhalt der HTTP-Nachricht berechnet. Repr-Digest gilt für die gesamte ausgewählte Repräsentation. Bei 206 kann der erste Wert das gelieferte Segment prüfen; der zweite kann das über mehrere Anfragen oder Verbindungen rekonstruierte Objekt bestätigen.

Ein Digest ersetzt den Validator nicht. Der Validator bindet Fragmente an dieselbe Version, Repr-Digest prüft die fertigen Bytes, und die Intervallabdeckung schließt Lücken oder verdeckte Überlappungen aus. Digest-Felder definieren außerdem keine Authentifizierung, Autorisierung oder Vertraulichkeit. R063 bleibt bei der engeren Frage, ob die abgerufenen Bytes eine kohärente Repräsentation ergeben.

Erstellen Sie ein Prüfprotokoll für die Bereichszusammensetzung

Eröffnen Sie den Nachweis, sobald die erste Teilantwort akzeptiert wird. Erfassen Sie Ziel-URI, Methode, auswahlwirksame Anforderungsheader, Kodierung, Medientyp, Gesamtlänge, starken Validator, Beobachtungszeit und Herkunft aus Ursprung, Vermittler oder lokalem Speicher.

Halten Sie für jedes Teilstück das gelieferte Intervall, Status, Validator, Quelle, Cache-Zustand und gegebenenfalls den Segment-Digest fest. Normalisieren Sie die Intervallmenge, damit Überschneidungen den Fortschritt nicht aufblähen und Lücken sichtbar bleiben. Verwerfen Sie jedes Fragment, dessen Identität der eingefrorenen Repräsentation widerspricht.

Schließen Sie den Nachweis erst, wenn die Intervalle die Repräsentation exakt abdecken und die rekonstruierten Bytes den erwarteten Repr-Digest oder einen unabhängig bezogenen Hash erfüllen. Ändert sich der starke Validator, fehlt er oder ist er mehrdeutig, muss die gemischte Montage verworfen und die aktuelle vollständige Repräsentation abgerufen werden. Das kostet Bandbreite, schützt aber die wichtigere Aussage, dass das verarbeitete Objekt als eine Version existierte.

Quellen