NNTP は失われた POST 応答をどう封じ込めたか

要約

失敗の境界をクライアント側から見ると奇妙である。もう送るデータはない。ヘッダー、本文、単独のピリオドからなる終端行まで届けた。それでも返答が届く前に接続が落ちれば、注入サーバーが受理した世界と拒否した世界は同じ沈黙に見える。

ここで新しい識別子を付けて再送すると、救済ではなく二本目の記事を作る可能性がある。再送しなければ、本当に失敗した投稿は消える。通信の欠落が、記事の存在数を左右する判断に変わる瞬間だった。

RFC 977 では、まずサーバーが 340 で記事送信を求め、投稿不可なら 440 を返す。クライアントが記事全体を送り終えた後になって、成功の 240 または失敗の 441 が返る。

つまり 340 は受理証明ではない。入力を始める許可である。RFC 3977 はこの二段階を引き継ぎ、POST のパイプライン化を禁じた。340 と 440 はコマンドへの直接応答、240 と 441 は終端シーケンス後の記事への判定として配置された。

240 は、予期しない障害がなければ、必要に応じてローカルで利用可能にするか他サーバーへ転送するという約束を表す。追加処理が先にあってもよい。不要な記事は 441 で拒否し、受け取って黙って捨てるべきではない。

RFC 3977 は、肯定応答を受け取らない限り成功を仮定してはならないとする。同時に、肯定応答を得ても他の読者から利用可能だと仮定せず、必要なら STAT などで確かめるよう求める。

RFC 5537 の役割分担を見ると、この注意は自然である。投稿エージェントが proto-article を作り、注入エージェントが検査して導入する。モデレーターへの転送、中継、閲覧サービスはその後の異なる仕事だ。一つの実装が兼務していても、証拠の意味までは一つにならない。

したがって、閲覧側でまだ見えないことは、以前の POST が拒否された証明にならない。モデレーション中なら、正しい投稿ほどすぐには見えない場合すらある。

RFC 3977 は最終応答受信前の切断を明記している。肯定応答が送信済みで失われた可能性があるため、後のセッションでは成功を確認してから再送するか、新しい試行にも同じ Message-ID が割り当てられるようにすべきだとした。

後者が推奨される。記事が審査中で、まだ閲覧検索に現れないかもしれないからである。付録は、メールまたは Netnews の記事なら各試行に同一内容の Message-ID ヘッダーを入れ、サーバーも二つの POST を同一記事として認識するよう勧める。

Message-ID は最初の処理が成功したという受領書ではない。投稿者認証でもない。再送が「別の記事」ではなく「結果を観測できなかった同じ記事」だと宣言する照合キーである。

RFC 5536 は Message-ID を一意な記事識別子とし、Netnews が高速比較に強く依存すると述べる。RFC 5537 では、洪水型伝播によって同じ記事が複数の相手から提示されるため、中継・サービスエージェントが既知 ID の履歴を持ち、重複を拒否する。

この仕組みが、失われた応答後の再試行にも役立つ。同じ ID なら一つの意図として突き合わせられる。新しい ID なら、本文が同じでも独立した審査・伝播・保存対象になる。

ただし履歴は永遠ではなく、サイトごとの方針も異なる。受理と永続化の間にも障害は起こりうる。同じ ID は exactly-once を保証しない。それでも、二つの似た記事ではなく、一つの記事に対する二つの試行として調査できる。

IANA の NNTP Parameters は POST 能力と RFC 3977 を登録する。この登録は共通名を与えるだけで、特定サーバーの投稿許可、履歴保持期間、現在の閲覧可能性を保証しない。

NNTP の選択は、未知を消すことではなかった。確認が消えた時に、回復処理まで別の名前を名乗らせないことだった。仕事の同一性を残せば、不確実性は照合できる範囲に留まる。