要約

  • STOU はパス引数を省略できる STOR ではない。引数ゼロの独立コマンドとして、現在ディレクトリ内の新名をサーバーが割り当てる契約を表す。
  • 任意コマンドであることは、未対応時にローカル名つき STOR へ黙って置き換えてよいという意味ではない。フォールバックは命名主体と衝突条件を変える。
  • 125 FILE:／150 FILE: の予備応答、後続の完了応答、REST、Unique=、アクセス制御は別々のインターフェース境界であり、省略された引数から自動的に補われない。

空欄ではなく、引数ゼロ

RFC 959 が示す形式は STOU <CRLF> である。STOR なら後ろに pathname が続くが、STOU には新しいファイル名の引数がない。これは値が空の pathname を渡すことでも、ローカルファイル名を暗黙に採用することでもない。サーバーが現在ディレクトリ内で一意な名前を作る、という別の命令である。

インターフェースとして見ると、引数の数が役割を凍結している。クライアントが選ぶのはコマンドと、それ以前のセッション状態で到達した現在ディレクトリまで。新規名の割当は、そのディレクトリを管理するサーバーが行う。クライアント実装が空いた欄を善意で埋めれば、命令は送信前から別の意味になってしまう。

一意性の範囲も文法の外へ広げられない。サーバーが約束するのは現在ディレクトリ内で衝突しない名前であり、世界規模の ID、永久名、内容の指紋ではない。省略された引数には、そのような追加情報が隠れているわけではない。

任意コマンドは暗黙の代替を許可しない

RFC 959 は STOU を七つの新しい任意 FTP コマンドの一つとして加えた。任意という位置づけは、すべてのサーバーが受理するという前提を置けないことを意味する。しかし、未対応応答を受けたクライアントが、同じ操作だとして STOR とローカル名へ自動的に切り替えてよい、という契約はそこから導けない。

二つのコマンドはデータの送り方が似ていても、名前空間の決定者が違う。STOU が拒否された後に STOR report.txt を送れば、サーバー割当を求めた操作が、クライアント指定位置への書込みへ変わる。既存ファイルがあれば置換の可能性も生じる。フォールバックが必要なら、それは上位の方針として明示的に選ばれるべきであり、パーサーが「同じ保存」として隠してよい差ではない。

RFC 5797 と現在の IANA FTP Commands and Extensions 登録 は、STOU を RFC 959 と RFC 1123 に結びつける任意の基礎コマンドとして記録する。登録の主目的は命令名と拡張名の衝突回避であり、個別サーバーの対応、普及、成功を示すものではない。基礎コマンド用の base FEAT code も登録上の不変プレースホルダーで、サーバーが FEAT に base と返すという意味ではない。

したがって、登録を見て対応を仮定するのも、FEAT の一語だけで意味を補うのも危うい。実際の命令応答と、未対応時にどの方針を取るかを分けて扱う必要がある。

現在ディレクトリは隠れた pathname ではない

STOU が新名引数を持たなくても、場所の文脈まで消えるわけではない。結果はセッションの現在ディレクトリに作られる。クライアントはその前にディレクトリを選んでいるかもしれず、サーバーはアクセス制御に従ってその状態を受理または拒否している。

ここで現在ディレクトリを「省略時のデフォルト pathname」と呼ぶと、二種類の決定が混ざる。ディレクトリ選択は名前空間の範囲を決め、新名割当はその範囲内の空き位置を決める。直前のディレクトリ変更が失敗したのに、クライアントがローカル状態だけ更新して STOU を送れば、サーバーとクライアントは異なる場所を想定する。命令文法が正しくても、セッション前提がずれていれば意図したキューには入らない。

1971 年の RFC 172 は、ファイルをシステム内の pathname で識別しながら、FTP がホストごとの命名規約を統一しないことを示した。利用者は遠隔ファイルシステムの作法に従わなければならなかった。STOU の省略は、この異種性を「名前は不要」として無視するのではなく、遠隔規則を知る側に新名選択を任せる。

同じ RFC は選択的アクセスを常駐ファイルシステムに残した。現在ディレクトリを知り、新名割当を頼めることは、書込み許可を証明しない。場所の状態、命名の責任、アクセス権は別の前提である。

新しい動詞が既存文法を守った

RFC 949 は 1985 年、プリンター、ファクシミリ、カード穿孔機のキューを例に一意名保存を提案した。検討されたのは、STOR を変更する案、引数を追加する案、引数なしの保存を特殊扱いする案である。最終的に新しい STOU が選ばれた。確立した STOR の処理を開き直すより、命令名による分岐を追加する方が容易だと考えられたからだ。

この判断は機能追加の仕方そのものを示す。既存コマンドの引数規則を文脈依存にすれば、古いクライアントと新しいサーバー、新しいクライアントと古いサーバーの間で、同じ文字列が別の意味を持ち得る。新しい動詞は未対応なら未対応と分かり、対応している場合だけ新しい責任分担へ入る。

RFC 949 は、生成した名前を応答に含めることも必須とした。名前を送らなかったクライアントには、サーバーの答えを受け取るインターフェースが必要である。ただし文書は、STOU がアクセス制御、認証、会計を回避するためのものではないと明記する。引数を省いたからといって、認可までサーバーの既定動作に委ねたわけではない。

プール提案でも名前の調整はサーバー側だった

1973 年の RFC 505 は、受取人のパスワードを知らない利用者が別ホストへファイルを届ける問題に対し、受取人の領域へ直接書かず、プールへ置いて通知する案を示した。提案の POOL id name は希望名を受け取るものの、サーバーが接頭辞や接尾辞を加えてプール内で一意にする。受取人、プール位置、名前調整、通知が分離されていた。

これは STOU と同じコマンド文法ではない。それでも、クライアントの希望名を遠隔空間の最終決定としない考え方を先に表している。高位プロトコルが異なる OS の詳細を知りすぎるという問題意識もあった。後に STOU が RFC 505 を半ば置き換えたという文献関係は、POOL の広範な配備を証明しない。互換性の系譜と採用の歴史は分ける必要がある。

応答にも最小文法が要る

RFC 959 は、生成名をいわゆる「250 Transfer Started」応答に含めると記した。しかし同じ RFC では、125 が既存データ接続で転送を開始する段階、150 がデータ接続を開こうとする段階、250 がファイル動作の完了である。STOU の応答表も 125 または 150 を先に、226 または 250 を後に置く。

RFC 1123 はこの不整合を直し、実際の pathname を転送前の 125 FILE: pppp または 150 FILE: pppp に置いた。数字コードだけで段階を、固定の FILE: でフィールド境界を表す。FTP の応答テキストはサーバー依存で人向けになり得るため、必須 pathname を自由文から推測させない最小文法が必要だった。

ここでも契約は限定される。予備応答は割り当てた名前を知らせ、後続の 226／250 は完了を知らせる。425、426、451、551、552 などの失敗は、名前を受け取った後にも起こり得る。FILE: を解析した時点で完了状態へ進む実装は、応答文法の二段階を一つに潰している。

RFC 1123 はさらに、User-FTP が遠隔 pathname を任意の文字列として受け入れ、ローカル OS の慣習を押しつけないよう求める。引数を省いた要求側だけでなく、サーバーから返る結果側にも互換性の規律がある。

省略は再開するファイルまで選んでくれない

RFC 3659 は、ストリームモードの REST 後に通常続く転送を RETR または STOR とする。サーバーが APPE や STOU を許す場合はあっても推奨されず、REST 後の STOU は未定義とされる。部分ファイルの残りを一意な新名に保存しても、元の部分ファイルを再開したことにはなりにくい。

省略された pathname から、以前の転送先ファイルを推論してはならない。REST は同じ既存ファイルと位置の共有を必要とし、STOU は新規名の割当を求める。パーサーが両方の命令を受理できることと、組合せに相互運用可能な意味があることは別である。

同じ RFC の Unique= ファクトも省略を埋めるものではない。等しい token は二つの pathname が同じ保存済みファイルを指すことを示すが、token は不透明で大文字小文字を区別し、対応の一貫性は少なくとも制御接続の期間に限られる。STOU の「現在ディレクトリで衝突しない新名」と、Unique= の「別の pathname が同じ保存済みファイルを指すか」は異なる契約である。

RFC 3659 は、保護を迂回できるファイルシステム識別子を公開 Unique= token の基礎にしないよう注意する。便利な既定値で内部 ID を露出する設計は、最小インターフェースの範囲を超える。

文法が正しくても安全とは限らない

RFC 2577 は、標準 FTP のパスワード、制御情報、データが暗号化されず、データ接続の奪取や置換にも危険があることを記録した。STOU の引数数と応答文法が正しくても、送信者の真正性、内容の機密性、データ相手の正当性は証明されない。サーバー割当名はアクセス権でもなく、後の名称変更や削除を防ぐものでもない。

最小共通契約の価値は、解決していない問題を既定値で隠さないことにある。STOU <CRLF> は名前を選ぶ主体を示し、FILE: は答えの場所を示し、完了コードは結果の段階を示す。認可、保管、複数の pathname が同じ保存済みファイルを指すかどうかは、別のインターフェースに残る。この狭さが、異なる実装間で同じ省略を同じ意味に保つ。