Summary

  • Revision 05 des Byte-Range-PATCH-Entwurfs beschreibt, wie ein Server Content-Range bei PUT ohne passende Unterstützung ignorieren und die ganze Ressource durch das Fragment ersetzen kann.
  • message/byterange bezeichnet einen zusammenhängenden Schreibbereich in einem PATCH-Dokument. Fehlt eine bekannte Position, muss der Server mit 400 oder 422 ablehnen.
  • Angegebene Teillängen müssen genau zur Bereichslänge passen. Bei erlaubten Lücken dürfen keine nicht initialisierten Daten offengelegt werden.

Der Entwurf führt ein Beispiel an, das jeden Werbesatz über „Updates in Blöcken“ erdet. Vorher enthält die Datei 0123456789 und einen Zeilenumbruch. An die Stellen 2 bis 5 soll wxyz. Danach soll 01wxyz6789 samt Zeilenumbruch stehen. Wenn PUT als vollständiger Ersatz behandelt wird, bleibt nur wxyz. Die Übertragung kann tadellos gewesen sein. Verloren ging die gemeinsame Bedeutung des Befehls.

Ein Content-Range-Feld im PUT ist für sich genommen kein Vertrag über einen Teilersatz. Abschnitt 2 des IETF-Textes verlangt dafür besondere Server-Unterstützung. Ohne sie darf der Server das Feld übergehen und den gesamten Inhalt ersetzen. Die absendende Software kennt den gewünschten Offset, die empfangende Software kennt ihre übliche PUT-Regel. Eine Datei wird zwischen zwei korrekten Annahmen zerrieben.

Der Vorschlag verschiebt den Befehl in ein PATCH-Dokument mit definierter Bedeutung. message/byterange umfasst einen Bereich; multipart/byteranges mehrere; application/byteranges soll eine binäre Form bieten. Das Dokument nennt die Position innerhalb des zu verarbeitenden Formats. Wer dieses Format annimmt, erhält damit einen expliziten Auftrag zum Schreiben an einer Stelle. Wer es nicht kennt, muss die Operation verweigern, bevor die Ressource verändert wird.

An der Dateigrenze endet jede Ausrede

Jeder Teil muss einen zusammenhängenden Bereich angeben. Bei unbekannter Stelle ist 400 oder 422 vorgeschrieben. Enthält ein Teil Content-Length, muss der Wert genau der Länge des Bereichs entsprechen. Ein Server soll weder eine fünfte Byteposition hinzuerfinden noch einen überzähligen Inhalt stillschweigend wegwerfen. Für einen Strom mit offenem Ende gibt es Content-Offset, das zumindest den Start nennt. Die Zukunft der Datei darf offen sein; der Anfang des Schreibvorgangs nicht.

Ein Sprung über das Dateiende erzeugt einen weiteren Unterschied. Direkt angrenzendes Schreiben verlängert die Datei. Ein weiter außen beginnender Teil lässt undefinierte Bytes zurück. Der Entwurf empfiehlt, solche Lücken abzulehnen. Bei erlaubten spärlichen Dateien muss der Server die Offenlegung nicht initialisierten Inhalts verhindern und sollte die Lücken mit Nullen füllen. Ein erfolgreicher HTTP-Code ersetzt die Prüfung des gespeicherten Ergebnisses nicht.

Abschnitt 4 behandelt mit Prefer: transaction=atomic und transaction=persist den Fall einer abgebrochenen Übertragung. Eine Antwort mit Preference-Applied soll zeigen, was der Server beachtet hat. Diese Präferenz entscheidet über Rücknahme oder Bewahrung empfangener Daten. Sie beantwortet nicht die frühere Frage, ob der kurze Körper in eine vorhandene Datei geschrieben oder zur gesamten neuen Datei erklärt wurde.

RFC 5789 kennt Accept-Patch zur Anzeige unterstützter Patch-Formate. Es fehlt ein öffentlicher Vergleich identischer Bereichs-PUTs und message/byterange-PATCHes auf verschiedenen Servern, mit Vorher- und Nachher-Bytes, Antwort und ETag. Die Messung würde zeigen, welche Seite den Befehl tatsächlich verstanden hat.

Entwurf und Stand · RFC 5789 · RFC 9110