Summary

  • Byte Range PATCH草案の第05版は、部分PUTを扱わないサーバーがContent-Rangeを無視し、送られた断片でリソース全体を置き換える危険を示す。
  • message/byterangeは一つの連続した範囲をPATCH文書に含める。位置の分からないパッチは、サーバーが400または422で拒否しなければならない。
  • 部分のContent-Lengthを示す場合、範囲の長さと厳密に一致させる。疎な領域を許すサーバーは未初期化データを漏らしてはならない。

草案の例を試すと、合意の欠落がすぐ分かる。元の内容は0123456789と改行。2番目から5番目の位置にwxyzを入れると、期待値は01wxyz6789と改行だ。ところが断片をファイル全体の新しい内容として受け取れば、結果はwxyzだけになる。送信側の指定は正確でも、受信側が約束した操作が違えばファイルは消える。

第2節は、PUTに付けたContent-Rangeの意味がサーバーの対応に依存すると説明する。部分PUTに対応していないサーバーは、そのフィールドを無視して通常の全体置換を行い得る。フィールドを付けた事実と、受信側が範囲を守るという保証は別だ。事故を起こすのは壊れた通信ではなく、互いに違う仕事をしている二つの正常なプログラムである。

草案はPATCHと専用の文書型を組み合わせる。単一範囲にはmessage/byterange、複数範囲にはmultipart/byteranges、さらにバイナリー形式としてapplication/byterangesを提案する。範囲の位置はパッチ文書の内部に入る。受信側は文書型を理解して書き換えるか、扱えない形式として拒む。静かな全体置換を許さないための境界が、メソッドと内容の組み合わせに移る。

書き込む位置を知らないなら、書き込まない

各部分には一つの連続した範囲が必要だ。位置が不明なら400または422で拒否する。部分にContent-Lengthがあれば、その値と範囲の長さは一致しなければならない。四バイトの範囲を名乗る五バイトの入力を、サーバーが都合よく解釈する余地をなくす。終点が分からないストリームにはContent-Offsetを使えるが、書き始める位置は指定する。

ファイルの端を越えると問題が変わる。末尾のすぐ隣に書くのは追加。離れた位置に書けば、間に定義されない領域ができる。草案はそのような書き込みを拒むよう勧める。

疎なファイルを許可するサーバーには、未初期化領域の内容を見せない義務がある。ゼロ埋めも勧められる。成功応答だけを見ていては、保存された内容の穴は見つからない。

中断時の扱いは別の選択だ。第4節のPrefer: transaction=atomicは成功後の確定を、transaction=persistは途中まで受け取った内容の保持を求める。適用した選択はPreference-Appliedで知らせることが勧められる。保持か巻き戻しかを決める前に、送られた断片がファイルのどこに属するかを決めなければならない。

RFC 5789のAccept-Patchは対応するパッチ形式の広告に使える。公開されていないのは、同じ範囲付きPUTとmessage/byterange PATCHを複数の実サーバーに送り、元のバイト列、応答、ETag、結果を並べた比較だ。その記録が実装上の境界を示す。

草案の版と状態 · RFC 5789 · RFC 9110