Summary

  • 10月27日付のCDNI作業部会草案第13版は、許可されたOrigin向けのワイルドカードCORS応答が、Varyを誤って扱う共有キャッシュから除外対象に渡る経路を明示した。
  • 草案はCORSの実際の判定場所も整理する。下流CDNは公開リソースを配信し、適合するブラウザーがその応答を別の配信元のスクリプトに見せるか判断する。

受付係は名簿どおりに客を通した。問題は隣のクロークで、渡した通行証の写しを別の客にも出してしまったことだ。CDNの世界では、通行証に当たるのがAccess-Control-Allow-Origin: *という応答ヘッダーである。IETFの新しい草案第13版は、正しい名簿確認の後でも共有キャッシュがこの印を別の要求へ運べると指摘する。

上流CDNはRFC 8006のメタデータインターフェースを使い、MI.CrossoriginPolicyを下流CDNへ渡す。下流は要求のOriginを許可リストと照合する。合致し、wildcard-returnが有効なら*を返せる。合致しなければ対応するCORSヘッダーを付けない。ただし*だけを見ても、最初にどの配信元が審査を通ったかは分からない。

そこで共有キャッシュが厄介になる。許可された配信元への応答を、要求の配信元で区別せず別の要求に使い回せば、名簿にない配信元のブラウザーにもワイルドカードが届きうる。改訂版の運用上の考慮事項はこの場合を明記した。下流CDNは生成したCORSヘッダーをキャッシュ内のリソース表現に固定せず、応答ごとに作る。また、CORSの結果を左右する要求ヘッダーをVaryに記す。

旧第12版からの改訂は、この設定の権限を大きく見せない点でも重要だ。CORSヘッダーは、適合するブラウザーが応答をスクリプトへ公開するかを決める材料だ。ヘッダーがなくても、下流CDNは一般公開リソースを配信する。ブラウザーが認証情報を含めるincludeモードの要求は、ここで定義する設定の対象から外れている。認証と認可の組み合わせは別の動作を要する。

到着時刻にも差がある。上流がリソースを公開した後、ポリシーが下流へ届くまで、下流はCORSヘッダーなしで応答しうる。その間、ブラウザーのCORS確認は失敗する。新しい運用節はRFC 8006の既存の仕組みで下流に現在ある設定を読み戻し、実際の応答と比べられると述べる。送った設定、届いた設定、客が受け取った応答を別々に見る必要がある。

IETFの文書情報では、第13版はIESG評価中のCDNI作業部会草案だ。受付の名簿が正しくても、出口の通行証を見なければ配信の判断を語れない。