要約

  • ALLO は STOR や APPE の前に必要な論理バイト数を申告し、レコード構造やページ構造では最大単位長も付けられる準備命令だった。
  • 事前割当てを必要としないサーバーは ALLO を無操作として扱い、肯定完了の 202 で単純なクライアントを先へ進ませることができた。
  • その応答が証明するのは「予約なしで続行してよい」という判断であり、空き容量、書込み完了、耐久性ではない。後続応答と生成物を一続きに検証する必要がある。

倉庫の比喩が通用しないホスト

ファイルを送る前に「二千万バイト必要だ」と知らせれば、受け手は場所を空けられる。現実の倉庫なら自然な段取りに見える。しかし初期のネットワークが結んだ計算機では、記憶領域の割当て方そのものが一致していなかった。先に容量を確保しなければファイルを作れないシステムもあれば、書き進めるたびに領域が増え、独立した予約操作を持たないシステムもあった。

1972 年の RFC 354 は、その違いを ALLOCATE (ALLO) の定義に残した。新しいファイルのために十分な記憶域を予約する必要があるサーバーでは、この命令が求められることがある。引数は選択中のバイトサイズで数えた十進整数で、その後には STORE または APPEND が続く。

一方、最大ファイルサイズを前もって宣言する必要がないサーバーは、ALLO を何もしない操作として扱う。つまり、標準は全ホストに同じディスク制度を押しつけなかった。送信側は計画値を出せるが、その値を資源へ変換する権限と必要性は受信側に残した。

1980 年の RFC 765 は申告を拡張した。最初の数値は論理バイトによるファイル容量である。レコード構造またはページ構造なら、最大レコード長・ページ長を第二の十進整数で加えられた。二つの値は空白、R、空白で区切る。後者だけを必要とするサーバーは、最初の値をダミーとして受け取り無視することになっていた。

ここで数えているのは FTP の表現に属する量である。ファイルシステムのブロック、利用者クォータ、圧縮後の転送量、永続媒体上の実占有量と同一ではない。ALLO は遠隔ディスク測定器ではなく、サーバーが必要なら解釈する計画メッセージだった。

202 は失敗を緑色に塗ったのではない

1985 年の RFC 959 は ALLO の二つの整数と、直後に STOR または APPE を置く規則を引き継いだ。最大サイズの事前申告が不要なサーバーでは NOOP として扱う点も変わらない。

応答規則には、異種システムをつなぐ工夫がより明確に書かれている。TYPE や ALLO のように、成功しても利用者プロセスへ新しい情報を与えない命令には 200 を返す。さらに、特定の計算機では意味がないため ALLO を実装していなくても、単純な利用者プロセスが処理を続けられるよう肯定完了応答が望まれる。その場合は 202 を使い、例として“No storage allocation necessary”を示す。

202 の一般文は「命令は実装されておらず、このサイトでは余分」である。重要なのは、未実装と続行可能が同時に成立することだ。予約操作をしていない以上、予約の受領証ではない。しかし、予約が不要な実装へ同じクライアント手順を通すという目的には成功している。

サイト固有ではない動作が未実装なら 502、命令はあっても指定パラメータが未実装なら 504 になる。202 は単なる都合のよい成功表示ではなく、要求の必要性についての局所判断を伝えるための区別だった。

200 についても、数字だけから物理的保証を作るべきではない。実際に領域を確保するサーバーはあり得るが、RFC が示すのは「成功し、新情報がない」場合の応答である。何ブロックを、いつまで、どのクォータから確保したかは、実装と運用の証拠なしには分からない。

保存を試した瞬間、別の応答系列が始まる

ALLO は準備であり、データを運ばない。STOR になって初めて、サーバーはデータ接続から内容を受け取り、指定名のファイルとして保存する。既存ファイルなら転送データで置き換え、存在しなければ作成する。この段階で接続、権限、パス、クォータ、空き領域が実際の仕事をする。

応答は段階を区別する。125 はデータ接続がすでに開き転送を開始すること、150 はファイル状態がよくデータ接続を開こうとしていることを知らせる。どちらも予備応答で、完了ではない。後には 226 や 250 の肯定完了があり得る一方、接続断、ローカル処理、パス、記憶域に関する失敗もある。

452 はシステムの記憶域不足により要求動作を実行しなかったことを示す。552 は現在のディレクトリやデータセットに対する割当てを超え、ファイル操作を中止したことを示す。先に 202 を受けていても矛盾しない。事前予約が不要だったことと、実書込み時に十分な容量があることは別問題だからだ。

証拠は時間とともに強くなる。ALLO 送信時にはクライアントの申告がある。202 後には予約なしで先へ進めるというサーバー判断がある。125 や 150 後にはデータ段階が始まる見込みがある。完了応答と最終ファイルのサイズ・内容を照合して初めて、保存について強い主張ができる。

RFC 3659 は、機械可読一覧の書込み許可について似た注意を置いた。許可表示があっても適切な命令の成功は保証されず、利用可能容量などシステム固有の制限で失敗し得る。許可は目安にすぎない。これは ALLO の再定義ではないが、資格表示と実行結果を混同しない原則を補強する。

オプションでも会話から消す必要はなかった

1989 年の RFC 1123 は、サーバーによる ALLO 対応を任意の欄に置いた。同時に、利用者 FTP プログラムには QUOTE を必須とした。任意の文字列をサーバーへ送り、返された応答をすべて表示する機能である。

解説は SITE と ALLO を例示する。クライアントが専用機能として理解していないサイト固有・任意の命令でも、利用者は明示的に試せる。標準クライアントを際限なく膨らませず、サーバー固有能力への観測可能な通路を残す設計だった。

IANA の FTP Commands and Extensions 登録簿 は現在も ALLO を基本命令“Allocate”として掲載し、RFC 959 を参照する。登録は語彙の所在を示す。個々のサーバーの実装、予約方式、空き容量、ある転送の完了を示す運用台帳ではない。

監査可能な記録は命令の後ろまで伸びる

ログを「ALLO success」に畳むと、200 と 202 の違いが消える。保存すべきなのは命令全文、両方の整数、当時の TYPE と STRU、数値コード、応答テキストである。後からサーバーが何を判断したのかを再現できなければならない。

そして直後の STOR または APPE と結びつける。データ接続は開いたか、何バイトを送受信したか、中断はあったか、最終応答は何か、対象ファイルは存在するか、サイズとハッシュは一致するか。容量を論じるなら、同時点の空き容量、利用者・ディレクトリのクォータ、競合書込みも必要になる。

FTP の最終肯定応答でさえ、永続保存、複製、将来の復元可能性を一括して証明しない。必要な性質は、生成物の再読出しや別媒体の検証で補う。ALLO が教えるのは応答を疑うことではなく、応答の対象を越えて結論を広げないことだ。

出典