要約

  • Content-Location は、メッセージ内の表現に対応する具体的な資源を識別する。意味は要求メソッド、応答ステータス、対象URIとの同一性によって変わるが、対象URIそのものを置き換えることはない。
  • ローカルコピーの更新、選択された変種の識別、処理報告の後日取得には役立つ。一方、転送、正規URL、共通所有者、後続GETや書き込みの許可は、このフィールドだけから導けない。

購入サービスへPOSTを送り、成功応答に領収書が入っていたとする。応答には Content-Location: /receipts/47 もある。ここで /receipts/47 を「今後のすべての操作先」に置き換えるのは簡単だが、プロトコル上は誤りである。

POSTが作用したのは取引サービスだ。本文が対応するのは領収書資源である。新しい資源を作ったなら、Location がさらに別の対象を示す場合もある。複数のURIは競合しているのではなく、異なる問いに答えている。

RFC 9110第8.7節は、その分業を厳密に保つ。内容の同一性を詳しく知らせても、経路、所有権、次のメソッドにまで権限を広げない。

要求対象は応答によって書き換わらない

対象URIは、メソッドがどの資源へ向けられたかを定め、ルーティング、認証、認可、監査の文脈になる。応答フィールドは返された表現を説明できるが、完了した要求の宛先を後から差し替えられない。

Content-Location の値は絶対URIまたは部分URIである。メッセージ内容として運ばれた表現に対応する、特定の資源を識別するために使える。RFCは時間を含む説明を置く。メッセージ生成時にそのURIへGETしたなら、200応答は同じ表現を含んでいたはずだ、という関係である。

部分URIは対象URIを基準に解決される。絶対形にして比較できるようになっても、役割は変わらない。仕様は Content-Location が対象URIの代替ではなく、表現メタデータだと明記する。

両方がアドレスに見えるため、自動化は一つへ畳みたがる。後から来た具体的なURIをデータベースの主キーにし、次の操作までそこへ送る。しかし「今回どの資源にメソッドを適用したか」と「返った文書がどの資源に対応するか」は別である。

Location も区別が必要だ。ステータスによって、新しく作られた資源を識別したり、リダイレクト先を示したりする。一つの応答が Location と Content-Location の双方を持てるのは、ステータス上の行き先と本文の資源が別の役割を持つからだ。

同じURIなら、本文の性質が分かる

2xx応答で、絶対化した Content-Location が対象URIと同じなら、受信者は本文をメッセージ生成日時における対象資源の現行表現とみなしてよい。

GETやHEADでは、フィールドがない場合の通常の意味と変わらない。成功したGETはもともと要求対象の選択された表現を返す。フィールドが新たな読み取り権を作るわけではない。

PUTやPOSTの後では区別に価値が出る。編集ツールが文書をPUTし、200応答の Content-Location がPUT先と一致していれば、本文は単なる「成功しました」という報告ではなく、更新後の資源表現である。ツールは追加GETをせずにローカルコピーを更新できる。

短縮されたのは往復であり、認可ではない。PUTを受理する権限判断は送信済み要求に対して行われた。応答フィールドは次回の更新を許可せず、状態の継続も他のキャッシュの同期も保証しない。

「メッセージ生成時」という限定も残す必要がある。後日のGETでは内容が更新され、別の変種が選ばれ、アクセス規則が変わるかもしれない。永続的なバイト同一性の証書ではない。

異なるURIには複数の読み方がある

成功応答で値が対象と異なる場合、メソッドとステータスを無視して一律に「移動先」と読むことはできない。

GETまたはHEADへの応答なら、内容ネゴシエーションを表し得る。対象URIは複数の表現を持つ資源で、Content-Location は今回選ばれた表現のより具体的な識別子になる。多言語の報告書で、日本語版に固有のURIを示す場面がそれに当たる。

具体的だからといって、ネゴシエーション対象を正規URIとして置き換えるとは限らない。広い対象は次の利用者に適した言語や形式を選ぶ入口として残る。固有URIは今回何が選ばれたかを示す。正規関係を主張したいなら、別の明示的な仕組みが必要だ。

状態変更メソッドへの201応答には別の組み合わせがある。Content-Location と Location が同じなら、本文は新規作成された資源の現行表現である。Location は201に基づいて新資源を示し、Content-Location は本文を説明する。同じ値でも職務は統合されない。

その他の成功した状態変更では、異なる値が操作結果の報告資源を示す。RFCの例は購入領収書だ。POST先は取引サービスであり、本文は操作を報告し、内容位置は将来GETできる領収書を識別する。

監査は、操作対象、作成資源、報告資源を別々に保存したい。一つの「最終URL」に上書きすると、後のGETやPUTが何を読む、あるいは変更するのか分からなくなる。

二つの資源が同じ所有者かはHTTPだけでは分からない

異なる Content-Location を送るとき、オリジンサーバーは、そのURIが同封表現に対応する別資源を識別すると主張している。RFC 9110はすぐに条件を付ける。両識別子が同じ資源所有者を共有するときだけ信頼できるが、その関係をHTTPでプログラム的に判定することはできない。

同一オリジンは有用な境界だが、所有権台帳ではない。共有ホスティングでは一つのオリジンに複数の無関係な主体が置かれ得る。逆に、一組織が複数オリジンを正当に管理することもある。技術運用者と編集責任者が違う場合もある。

重要な効果を持つクライアントは、アプリケーション固有の証拠を必要とする。認証されたアカウント関係、審査済み名前空間、範囲を定めた署名付きマニフェスト、あるいは人の確認などである。

HTTP Message Signaturesも所有権判断を自動化しない。RFC 9421は選択したメッセージ要素の完全性をアプリケーションプロファイルの下で保護できるが、それ自体は完全なセキュリティシステムの一部にすぎない。署名でフィールドが無改変だと分かっても、署名者が共通所有を主張できるか、次のメソッドを許せるかは別の評価となる。

発言が改ざんされていないことと、発言者に決定権があることは同じではない。

要求内のフィールドは来歴であって、第二の宛先ではない

ユーザーエージェントは要求にも Content-Location を付けられる。この場合、自分が変更する前の表現を元々どこから得たかを示す。元資料へのバックリンクである。

オリジンサーバーはそれを一時的な要求文脈として扱い、表現のメタデータとしてそのまま保存してはならない。処理の参考や、適切な出典・版情報として使うことはできるが、要求の意味を変えるためには使えない。

RFCはネゴシエーション資源へのPUTで説明する。クライアントはある変種を編集元にし、そのURIをフィールドに書く一方、PUT自体は広い資源へ送る。サーバーがリダイレクトせず受理したなら、更新対象はPUTの対象である。フィールドを逆方向の選択子にして、その変種だけを更新することはできない。

変種だけを更新したいなら、PUTを直接そのURIへ送るべきだ。要求行、アクセス制御、監査記録が同じ資源を名指しする。

この規則がなければ、許可された要求対象の陰に第二の書き込み先を隠せてしまう。ゲートウェイは表のURIを認可し、アプリケーションは裏のURIを変更し、事後記録が食い違う。

出典文脈と操作範囲はどちらもURIで書けるが、同じ権限を持つわけではない。

キャッシュ無効化は限定された別機能

RFC 9111は、不安全メソッドへの非エラー応答後、キャッシュが対象URIの保存応答を無効化するよう定める。Location と Content-Location のURIも候補にできる。

ただし候補が要求対象と異なるオリジンなら、キャッシュは無効化してはならない。この境界は、一つのサイトへの書き込みを使って別サイトのキャッシュを消耗させる攻撃を防ぐ。

無効化とは、保存応答を削除するか、再利用前に必ず検証が必要な状態へ移すことである。オリジン資源の変更でも、世界規模の削除でも、利用者の転送でもない。要求が通過したキャッシュしか影響を受けないため、仕様も全キャッシュでの完了を保証しない。

同じフィールドから明示的に定義されたキャッシュ効果が生まれても、その効果はキャッシュの整合性管理に限られる。ブラウザーの移動命令、編集者のPUT権限、検索エンジンの正規化判断へ類推してはならない。

表現が具体的でも、URIが正規になるとは限らない

内容ネゴシエーションは、言語、形式、符号化などで複数の表現を選ぶ。Content-Location は今回運ばれた一つに具体的な識別子を与えられる。

これはローカル保存や来歴追跡に役立つ。将来同じ報告を取得する足掛かりにもなる。しかし、具体性は序列を作らない。変種URIが広い対象を追放する必要はなく、広い対象がすべての利用場面で優先されるとも限らない。

Web Linkingには資源間の型付き関係を示す別の仕組みがある。canonicalやalternateなどを主張するなら、それぞれの定義と政策を使うべきだ。Content-Location を暗黙の万能関係にすると、相互運用性は各製品の思い込みに依存する。

出版自動化では連鎖が起きやすい。具体URIを受け取り、正規インデックスへ登録し、次回編集をそこへ送り、署名対象まで変える。一つ一つは小さな省略でも、最初のフィールドが約束したのは「生成時にこの表現がこの資源へ対応した」ということだけだ。

対象URI、ステータス、Location、Content-Location、ネゴシエーション条件、認証済み相手、時刻を別項目で保持すれば、後の判断がどの証拠を使ったか分かる。

共通語彙とローカル判断を両立する

IANAのHTTPフィールド名登録簿は Content-Location を恒久登録し、RFC 9110第8.7節を参照する。これにより各アプリケーションは同じ表現概念を同じ名前で扱えるが、世界のURI所有者を決める機関が生まれるわけではない。

構造はLu Hengの順序に合う。最小初期仕様は、構文、URI解決、メソッド・ステータス・同一性による意味の表を共有する。将来の判断はローカルに残る。オリジンは何を主張できるかを決め、クライアントは所有権証拠を評価し、キャッシュは同一オリジン境界を守り、編集ツールはローカルコピーの更新を判断する。

受信者は必要な用途だけを採用できる。変種や領収書やキャッシュ無効化のたびに中央許可機関へ問い合わせる必要はない。共通意味を小さく保つことは分断ではなく、将来の権限を不必要に集中させない相互運用である。

URIを上書きせず、表現受領記録を残す

堅牢な実装は、メソッド、対象、ステータス、日時、解決済み Content-Location、Location、ネゴシエーション条件、認証済み相手、本文ハッシュを一つの受領記録に残す。

次に、規範上の類型を記す。対象の現行表現、選択変種、新規作成資源の表現、または操作報告である。「URIがあれば追う」という一律ルールは置かない。

効果も別々に記録する。編集ツールのコピー更新、後日GET、同一オリジンのキャッシュ無効化、正規関係の提案は、異なる根拠を要する。署名を使う場合は、覆った要素と署名者を受け入れた信頼プロファイルを記す。

そして修正を許す。後日取得した内容は変わり得る。変種は消え、所有権の証拠は撤回され、誤ったフィールドは訂正される。元メッセージは歴史的証拠として残り、恒久的な経路命令にはならない。

Content-Location は「この表現がどの資源に対応するか」という狭い問いに答える。次にどこへ行くか、どのURIを正規とするか、誰が双方を所有するか、どの操作を許すかは答えない。その節度が、小さなメタデータを長く使える協調手段にしている。

出典