Zusammenfassung

  • draft-ietf-httpbis-resumable-upload-12 definiert Upload-Offset als von der temporären Upload-Ressource verarbeitete Repräsentationsbytes und als Zusage, diesen Präfix nicht erneut übertragen zu müssen.
  • Selbst offset == length beweist keinen expliziten Abschluss, keine Integrität, keine aktuelle Autorisierung und keinen Commit der Zielressource; jeder Übergang braucht ein eigenes zurechenbares Ergebnis.

Die Repräsentation war mit zehn Gigabyte angekündigt. Nach mehreren Unterbrechungen meldete die Upload-Ressource exakt zehn Gigabyte Offset. Ein Controller sah Gleichheit, schloss den Vorgang und löschte die lokale Quelle.

Der Client hatte Upload-Complete nie auf wahr gesetzt. Die letzte Anfrage war abgebrochen, bevor die Zielressource ihre Semantik anwenden konnte. Die Zahlen waren korrekt und die Zustandsmaschine des Controllers falsch.

Revision 12 von Resumable Uploads for HTTP wurde am 6. Juli 2026 veröffentlicht. Es ist ein aktiver Internet-Draft der HTTP Working Group, für den Standards Track vorgesehen und bis 7. Januar 2027 gültig. Es ist kein RFC, kein Produktionsbericht und kein Nachweis von Interoperabilität oder Verbreitung. Gerade als Entwurf zeigt es jedoch, wie präzise ein fortsetzbarer Transfer seine Zustände trennen muss.

Ein temporäres Objekt trägt noch keine Zielsemantik

Die ursprüngliche Anfrage richtet sich an eine Ressource, deren Methode eine Anwendungswirkung besitzt. Der Server kann daneben eine temporäre Upload-Ressource erzeugen, die genau eine Repräsentation aufnimmt. Über sie werden Fortschritt abgefragt, Daten angehängt oder der Vorgang abgebrochen.

Diese Trennung ist ein Autoritätsmodell. Die temporäre Ressource verwaltet Kontinuität. Die ursprüngliche Zielressource entscheidet über Erzeugung, Ersatz, Annahme oder Ablehnung. Eine gültige Upload-URI ist kein Beleg, dass das Zielobjekt existiert. Schreibzugriff auf den Zwischenzustand ist auch keine dauerhafte Berechtigung für die endgültige Aktion.

Nach dem Abschluss darf der Server die Upload-Ressource sofort entfernen oder für spätere Verifikation behalten. Ein Client, der die letzte Antwort verloren hat, kann bei Aufbewahrung nachfragen. Ohne bekannte Retentionsregel bedeutet späteres Nichtfinden weder automatisch Erfolg noch Scheitern.

Der Offset ist näher an der Anwendung als ein ACK

Der Offset zählt jene Bytes der Repräsentation, die die Upload-Ressource verarbeitet hat. Transportzustellung und Transportbestätigung können weiter sein als dieser Wert, weil Daten noch gepuffert und nicht in den Anwendungszustand übernommen sind.

Eine Offset-Antwort ist dennoch eine belastbare Quittung. Der genannte Präfix muss nicht erneut gesendet werden. Der Client kann Wiederholpuffer freigeben und seine dauerhafte Sendeposition verschieben.

Die Quittung sagt nichts über den finalen Speicher, Replikation, Inhaltsprüfung, Digest, Freigabe oder Veröffentlichung. Ihr Satz lautet nicht „das Objekt wurde angenommen“, sondern „diese Repräsentationsbytes wurden von dieser Upload-Ressource verarbeitet“.

Der Wert darf nicht sinken. Verliert der Server einen Teil des Zustands, muss er die Ressource deaktivieren und weitere Interaktion ablehnen. Eine geschätzte Rückkehrposition würde Monotonie simulieren und könnte Lücken oder Duplikate erzeugen.

Vollständigkeit ist kein Rechenergebnis

Die Länge gibt die Größe der Repräsentation an, sobald sie bekannt ist. Der Offset gibt den verarbeiteten Präfix an. Der Entwurf stellt klar, dass ihre Gleichheit nicht über den Abschluss entscheidet.

Ein Stream kann gerade keine weiteren Bytes liefern, ohne geschlossen zu sein. Ein Client kann alle Daten in früheren Anfragen gesendet haben und erst mit einem leeren PATCH den Abschluss erklären. Upload-Complete bildet diese Entscheidung als eigenen booleschen Zustand ab.

In einer Antwort auf Erstellung oder Anhang bedeutet wahr, dass die Semantik der ursprünglich adressierten Ressource gilt. Eine Zielressource kann früh antworten, sodass der Wert wahr wird, obwohl nicht die gesamte Repräsentation übertragen wurde. Abschluss ist eine Protokollentscheidung, nicht bloß die Feststellung „alle erwarteten Bytes sind da“.

Ein Betriebsmodell braucht daher mindestens drei Anzeigen: verarbeiteter Präfix, bekannte Gesamtlänge, expliziter Abschluss. Erst danach folgen Integrität und Ergebnis des Ziels.

104 ist vorläufige Wiederaufnahmefähigkeit

Mit 104 Upload Resumption Supported kann der Server früh die temporäre URI und Grenzen mitteilen. Weitere vorläufige Antworten können während der Verarbeitung Offset-Fortschritt tragen. Diese Information macht eine spätere Fortsetzung möglich.

Sie ist keine finale Antwort. Bei optimistischer Erstellung beginnt der Client sofort mit der vollständigen Repräsentation. Kommt die Unterbrechung vor der 104-Antwort oder entfernt ein Intermediär sie, kennt der Client möglicherweise keine URI, obwohl der Server bereits Daten hält.

Die vorsichtige Strategie erstellt zuerst einen leeren Upload, erhält URI und Limits und sendet dann. Eine zusätzliche Runde erkauft einen sicheren Rückkehrpunkt. Beide Strategien lassen die Entscheidung bei der Zielressource.

Konflikt hält zwei Cursor auseinander

Jeder Anhang enthält den Offset aus Sicht des Clients. Weicht er vom Serverzustand ab, antwortet der Server mit 409 Conflict, seinem Offset und dem Abschlussstatus. So kann eine verlorene Antwort nicht unbemerkt zur doppelten Einfügung führen.

Der Client muss den Zustand neu lesen, die Identität seiner Quelle prüfen und nach einer definierten Regel fortfahren. Blindes Wiederholen ab dem lokalen Cursor kann bereits verarbeitete Bytes verdoppeln. Blindes Vertrauen in einen fremden Cursor kann Daten einer anderen Quelle verbinden.

Parallele Übertragungen für dieselbe Upload-Ressource werden nicht unterstützt. Anhänge und Abbruch sind zu serialisieren. Trotzdem benötigt eine verlorene finale Antwort eine nachträgliche Abfrage und eine idempotente Zieloperation.

Integrität beginnt nicht beim Fortschrittszähler

Digest-Felder haben eigene Abdeckung und Prüfschritte. Ein korrekter Offset beweist weder, dass ein Digest verlangt wurde, noch dass die zusammengefügten Bytes damit übereinstimmen. Codierte Repräsentationsdaten bestimmen Offset und Länge; Transfercodierung wird zuvor entfernt. Auch diese Schichten dürfen nicht verwechselt werden.

Ein Scanner, der jede PATCH-Nachricht einzeln als vollständiges Objekt betrachtet, kann ein über zwei Anhänge verteiltes Muster übersehen. Der zusammengesetzte Inhalt muss vor Ausführung, Veröffentlichung oder sensibler Verarbeitung geprüft werden. Metadaten bleiben ebenfalls nicht vertrauenswürdig.

Fortsetzbarkeit verschiebt die Einheit der Kontrolle. Sicherheitsmechanismen, die von einer einzigen vollständigen Anfrage abhängen, müssen auf die fertige Repräsentation oder auf beide Ebenen angewandt werden.

Die URI überlebt möglicherweise ihre Berechtigung

Die Upload-URI kann den Zwischenzustand verändern. Sie sollte schwer zu erraten sein, und nur autorisierte Clients dürfen zugreifen. Geheimhaltung ist jedoch keine vollständige Zugriffskontrolle.

Zwischen Erstellung und Abschluss können Stunden liegen. Rolle, Quota, Vertrag oder Freigabe können sich ändern. Der Entwurf weist auf dieses Zeitfenster hin und verlangt, Privilegien und Quoten vor Finalisierung erneut zu prüfen.

Damit entsteht eine klare Beweiskette: Transportzustellung; verarbeiteter Präfix; abgeglichener Offset und Länge; expliziter Abschluss; Integrität und Inhaltsregel; aktuelle Autorisierung; Commit des Ziels; nachgelagerte Wirkung. Eine wahre Stufe enthält nicht automatisch die nächste.

Quellen und Grenzen

Das eingefrorene Paket umfasst Revision 12, Datatracker-Historie, die HTTP-Arbeitsoberfläche sowie RFCs zu HTTP-Semantik, Caching, HTTP/1.1, HTTP/2, QUIC, Digest Fields, PATCH, Problem Details und Content-Disposition. Es belegt Mechanismen, nicht Implementierungsanteil, Leistung, Vorfälle, Interoperabilität oder Verhalten bestimmter Anbieter.

Quellen