要約

  • ISTag は ICAP サービスのソフトウェアや設定状態を比較するためのサービス単位の識別子であり、署名、内容判定、全ノード更新の証明ではない。
  • ルール変更を有効にするには、タグ生成、ノード展開、OPTIONS 更新、旧タグ付きキャッシュの失効、次の HTTP ホップとアプリ結果までを別々の記録で結ぶ必要がある。

管理画面では新しいルールが有効になっていた。大半の ICAP ノードは新しい ISTag を返した。しかし一台だけが旧タグを出し続け、クライアントはその時代に作られた結果をキャッシュから再利用した。

ルールファイルの保存は成功している。制御面の展開ジョブも成功している。それでもデータ面では、取り消したはずの判断が生きていた。失敗したのはルールそのものではなく、「どの時代のサービスが、どの結果を作ったか」という結合だった。

RFC 3507 は 2003 年 4 月に Informational RFC として公開された。ICAP は HTTP メッセージをカプセル化して適応する独立 TCP プロトコルで、HTTP そのものでも HTTP 上のプロトコルでもない。IESG は、既に使われていた技術を記録する文書であり、RFC 3238 が示した OPES のアーキテクチャーや政策問題を扱わないとも明記した。

ISTag は一つの表現ではなくサービスを指す

RFC 3507 はすべての ICAP 応答に ISTag を要求する。値はサービスのソフトウェア、設定、判定データなどの状態を表現できる。変更によって以前の適応結果が無効になるなら、タグを変えることでクライアントは旧状態に結び付いたキャッシュを捨てられる。

HTTP の ETag は通常、一つの選択表現を検証する。ISTag の範囲は広く、サービス URI が生成した多くのエンティティにまたがり得る。したがって、タグの変化は一件のコンテンツ更新ではなく、判定面の世代交代になり得る。

だがタグは暗号学的証明書ではない。内部のルール集合を開示せず、誰が承認したかも、全クラスタが同時に切り替わったかも示さない。同じ旧タグを複数ノードが返しても、それが正しい展開だとは限らない。

タグ生成とタグ展開は別の操作である

安全な更新には少なくとも四つの時点がある。設定が承認された時、そこから新しいタグが導出された時、各ノードが新設定を有効にした時、旧タグに属するキャッシュが利用不能になった時である。

一つのデプロイ成功時刻にまとめると、部分展開を見落とす。ノードは新コードと旧データの組み合わせで動くことも、再起動後に古い OPTIONS 応答を配ることもある。

証跡はタグを、署名済みまたは認証済みの設定マニフェスト、ノード ID、起動ハッシュ、有効化時刻、失効イベントに結び付けるべきだ。タグの値だけをログに残しても、その意味は後から復元できない。

OPTIONS の寿命はルールの寿命ではない

OPTIONS は対応メソッド、Preview サイズ、転送処理、Allow、最大接続数、オプション有効期間、現在の ISTag を広告する。クライアントはその応答を一定時間再利用できる。

しかし OPTIONS の有効期限、適応結果のキャッシュ期限、サービス設定の有効期間は別の時計である。OPTIONS がまだ新鮮でも、緊急ルール変更でタグが変わることがある。逆に新タグを観測しても、旧 OPTIONS や旧結果が残っている可能性がある。

RESPMOD では、適応された源オブジェクトの期限は元のオブジェクトより後に延ばせない。これは源の鮮度を守るが、サービスの判定時代までは保証しない。キャッシュ利用には両方の境界が必要である。

Preview はタグ付きの観測範囲を作る

ICAP Preview では、クライアントがカプセル化された全ヘッダーと、サービスが広告した上限までの本文を送る。サービスは変更結果、204 No Content、または残りがある場合の 100 Continue を返す。

したがって、ある ISTag に結び付く判定にも観測範囲がある。タグが最新でも、サービスが見たのが本文前半だけなら、判定を全文へ拡張できない。逆に本文全体を見ても、旧タグなら現在のルールによる判定ではない。

記録には requested Preview、実受信バイト、ieof、最初の未観測バイト、最終応答を含める。サービス時代と入力範囲を組にして初めて比較できる。

ieof は全文到着を線上で示す

源が Preview 中に終了すると、クライアントは最後のチャンクに ieof 拡張を付ける。サービスは本文の終端を受け取ったと知り、100 Continue で残りを要求してはならない。

サービスはアプリケーションへ渡す前に ieof を取り除く。エンジンの入力だけを保存すると、全文だと判断できた根拠が失われる。パケットだけでは、除去後にエンジンが何を処理したかが分からない。

ワイヤーとアプリケーション入力の二つを関連付ける必要がある。ISTag はその処理時代を与えるが、終端そのものは ieof と読取状態が与える。

204 は安全判定ではなく復元契約である

Preview 中の 204 No Content は、クライアントが元のメッセージを変更なしとして継続できることを示す。帯域を節約できるのは、クライアントが Preview 部分を保持し、残りにもアクセスできるからである。

Preview 外で 204 を使うには、クライアントが Allow: 204 を示し、元オブジェクトを復元する責任を引き受ける。許可がなければ、サービスは変更しない場合でも完全な同一メッセージを返す必要がある。

ゆえに 204 は「無害」を意味しない。サービスが変更を望まない、またはできない場合も含む。タグが最新でも、204 一つからマルウェア不在、出所真正性、政策適合を導けない。

変換結果には別の来歴が生まれる

REQMOD は変更済み要求、適応サービスが作った HTTP エラー、許可された 204、または ICAP エラーを返し得る。適応サービス由来の HTTP エラーを源サーバーの判断として記録してはならない。

RESPMOD の入力は源応答だが、出力は消費者へ届く前に変更される。変換成功は受信、表示、保存、業務処理の成功ではない。

前後ハッシュ、変換規則、サービス URI、ISTag、次ホップ結果を保持する。最終のアプリケーション効果は認証された別証跡として残す。

カプセル化のオフセットは境界を示すだけだ

Encapsulated ヘッダーは要求ヘッダー、要求本文、応答ヘッダー、応答本文、OPTIONS 本文または null 本文の開始位置を示す。複合メッセージを分解できても、埋め込まれた HTTP の意味や変換の妥当性を保証しない。

チャンク、Preview 終端、ieof、ICAP 状態、埋め込み HTTP 状態は別レイヤーである。再シリアライズした HTTP だけを保存すると、どのサービスがどのバイトを見たかを説明する境界が消える。

ルールの権限はタグの外側にある

RFC 3238 と後続 OPES 文書は、同意、通知、プライバシー、URI、参照整合性、ディスパッチ規則、信頼ドメイン、トレースを扱った。それらは全 ICAP 配備を OPES と呼ぶ根拠ではなく、ISTag に自動で政策権限を与えるものでもない。

必要なのは、誰の規則がサービスを選び、どの信頼領域でコンテンツへアクセスし、誰に変換を通知したかという外部記録である。タグは比較キーであって委任状ではない。

旧判定を止めるための証跡

原 HTTP、役割、観測点から始める。ICAP URI、メソッド、認証された相手、OPTIONS、期限、タグを保存する。カプセル化オフセットを検証する。

Preview の要求値と実値、ieof、源の読取状態、クライアントバッファ、暫定と最終応答、サービスが実際に見たバイトを記録する。

変換なら前後、キャッシュならキーと期限とタグ、204 なら元データ復元を証明する。そしてノード展開、タグ分布、旧タグ失効、次 HTTP ホップ、受信者、認証された業務結果までつなぐ。

証拠の境界

この記事は現在の製品、ベンダー、プロキシ、事件を特定しない。ISTag やキャッシュが危険だとも主張しない。比較可能な識別子を、配備証明や内容証明に拡張しないだけである。

既存の HTTP 100 Continue 記事とも重複しない。そちらは HTTP ヘッダー境界で本文を送る許可を扱う。ここではサービス全体の判定時代と、カプセル化された適応結果の再利用を扱う。

Heng Lu の最小初期仕様と running code の原則は、明示した編集上の視点である。細い共有契約と実動経路の証跡を重視するが、ICAP 配備の測定値ではない。

結論は限定的である。新しいルールが存在しても、新しいタグが全ノードと全キャッシュに到達した証拠がなければ、旧い判断は終わっていない。

Sources