要約

  • draft-ietf-httpbis-resumable-upload-12 の 104 Upload Resumption Supported は暫定応答であり、一時アップロードリソースの URI や進捗を通知するが、元の対象操作の最終結果ではない。
  • Upload-Offset、既知長、Upload-Complete、ダイジェスト、全体スキャン、現在の認可、対象リソースのコミットを別の証拠として扱わなければ、復旧機能が誤った成功通知を速める。

画面に最初の 104 が届いた。ライブラリは「再開をサポート」と正しく解釈した。ところがイベント変換層は 1xx を扱う欄を持たず、「サーバー応答あり」を成功へ写像した。利用者には完了通知が届き、実際の最終応答は接続切断で失われた。

サーバーが約束したのは、途中状態へ戻る入口だった。対象オブジェクトの成立ではない。

2026 年 7 月 6 日公開の Resumable Uploads for HTTP revision 12 は、中断された HTTP アップロードを再開する仕組みを定める。HTTP ワーキンググループの active Internet-Draft で、Standards Track を意図し、2027 年 1 月 7 日に失効予定である。RFC、普及統計、相互運用試験、実運用の報告ではない。それでも、暫定状態と最終判断を分ける設計は、運用上の重要な境界を示している。

104 が作るのは帰還座標

サーバーは初期要求を処理しながら、104 で一時アップロードリソースの URI と制限を早く返せる。その後も処理済みオフセットを含む 104 を送れる。クライアントは接続が切れても URI を手掛かりに状態を問い合わせ、残りだけを送る。

この早い通知が再開可能性を生む。楽観的な作成では、クライアントは最初から表現全体を送り始める。104 を受け取った後に中断すれば回復しやすい。しかし中断が早すぎる、中間装置が暫定応答を落とす、または対象が再開機能を提供しない場合、クライアントは URI を知らない。

慎重な作成は空の要求で先に一時リソースを確保し、URI と制限を得てからデータを送る。往復は一回増えるが、大きな表現を賭ける前に帰還座標を持てる。どちらを選んでも、104 は元の対象リソースの最終回答にはならない。

一時リソースは運搬の帳簿である

元の要求先は、POST や PUT の意味を決める対象である。そこから分離された一時リソースは一つの表現だけに属し、進捗照会、追加、取消を受け持つ。サーバーはその状態を保存し更新する。

この帳簿があるから、切断前に処理された部分を再送せずに済む。同時に、帳簿と対象を同一視してはいけない。一時 URI が存在しても最終オブジェクトは存在しない場合がある。追加権限を持っていても、対象操作を完了する現在の権限があるとは限らない。

完了直後に一時リソースを削除する実装も、最終応答を失ったクライアントの確認用に残す実装も可能である。後から URI が見つからないという事実だけでは、成功と失敗を区別できない。保持契約と対象側の記録が必要になる。

Offset はアプリケーション処理の受領証

Upload-Offset は、表現データのうちアップロードリソースが処理したバイト数である。トランスポートが配送し ACK を返した量ではない。ネットワークの受領と、アプリケーションが再開状態へ組み込んだ量の間には差があり得る。

応答で offset を返すことには強い意味がある。その前までの表現データは処理済みで、再送を要求しない。クライアントは再送用バッファを解放できる。正確な継続点は、プロトコルの中心的な価値である。

ただし受領証の対象は前置部分だけである。最終保存、複製、内容検査、ダイジェスト一致、対象の受理、公開を証明しない。進捗を「成功率」と呼べば、狭い証拠に広い権限を持たせることになる。

offset は減少してはならない。必要な状態を失ったサーバーはリソースを無効化し、続行を拒否する。推測した位置から続けるより、連続性が失われたと明示する方が安全である。

長さと完了は一致しなくてよい

表現の長さは最初から分かる場合も、ストリームの終端で初めて確定する場合もある。offset が length と同じでも、アップロードは不完全であり得る。二つの整数の一致は、明示的な完了操作を代行しない。

Upload-Complete は独立した真偽値である。全データを前の要求で送った後、空の追加要求で完了を宣言することもできる。逆に長さが既知でも、クライアントがまだ閉じていないなら不完全のままである。

作成または追加への応答で真なら、元の対象リソースの意味が適用される。対象が早期応答を選ぶと、表現全体を転送していなくても真になることがある。従って「完了」は常に「全バイト受信」の別名ではない。対象が処理を終える判断をしたという状態である。

409 は記憶の差を止める

追加要求には、クライアントが考える現在の offset が入る。サーバーの値と違えば 409 Conflict が返り、サーバー側の offset と完了状態が示される。失われた応答や遅い再試行が、同じ部分を二重に差し込むことを防ぐ。

クライアントは状態を再取得し、元の表現が同一かを確かめ、定義した再試行規則で進む必要がある。ローカル値を押し通しても、差分を単純に再送してもいけない。サーバーだけが持つ四メガバイトは、返答が消える前にすでに処理されたものかもしれない。

同じ一時リソースへの並列転送は許されない。追加と取消は直列化される。しかしサーバー内部の直列化は、クライアントが失った最終応答を復元しない。対象操作の冪等性と事後照会は別途設計する。

分割された安全検査を組み直す

正しい offset は完全性を保証しない。コンテンツと表現のダイジェストには独自の対象と検証規則がある。何を計算し、いつ比較し、失敗時にどこまで無効化するかを記録しなければならない。

再開可能な追加は、安全検査の盲点にもなる。各 PATCH を完全なファイルとして調べるスキャナーでは、二つの要求にまたがる危険なパターンを見落とす。組み立てた表現全体を、実行、公開、解析の前に検査する必要がある。

メタデータも信頼できない入力である。正しいバイト位置は、ファイル名、メディア型、保存先の安全性を証明しない。転送の継続性と内容の可否は異なる管理面に属する。

開始時の権限は時間で古くなる

一時 URI は変更能力を持つ識別子なので、推測しにくくし、認可済みクライアントだけが利用できるようにする。しかし URI の秘密性は、認証や認可の代わりではない。

長いアップロードの途中で役割、契約、クォータ、案件状態は変わる。作成時の許可だけで最終化まで通すと、確認時点と利用時点の差が脆弱性になる。草案は最終化の前に、権限とクォータが今も有効か再確認するよう求める。

運用が必要とする証拠列は、配送、アプリケーション処理済み前置部分、offset と length の同期、明示完了、完全性と内容方針、現在の認可、対象のコミット、下流結果である。104 はこの列の入口を確保するが、終端を証明しない。

出典と限界

凍結資料は revision 12 と履歴、HTTP 作業面、HTTP セマンティクスとキャッシュ、HTTP/1.1、HTTP/2、QUIC、Digest Fields、PATCH、Problem Details、Content-Disposition を含む。仕組みと注意点を裏付けるが、実装比率、性能、実際の侵害、相互運用、特定事業者の挙動は示さない。

出典