[14] challenge の domain 引数は、 保護空間の URL のリストを指定するものです。

[17] ここでいう「domain」は、ドメイン名の意味ではなく、 セキュリティー的な対象の範囲を意味しているようです。値はドメイン名ではなく、 URL です。

仕様書

意味

[4] domain 引数は、保護空間を定義するものです >>3。

構文

[16] auth-param の引用文字列構文を使わなければなりません >>3。

[5] RFC 3986 URI の間隔space区切りのリストです >>3。

[6] 間隔の定義は不明です。 RFC 2617 時代は 1つ以上の SP と明記されていました >>2 が、 RFC 7616 ではなぜか削除されています。

[7] URI が path-absolute であれば、正準根URLを基底URLとします >>3。

[12] 他の相対URLの場合の基底URLは謎です。[19] URI は RFC 2617 時代は absoluteURI または abs_path とされていました >>2 が、 RFC 7616 でそのような制限は明記されていません。制限を緩和して基底URL の規定を忘れたのか、誤って制限の規定を削除してしまったのかは謎です。 (どちらにしても杜撰な話ですが、 IETF ではままあることです。)

[8] URI は、異なる起源のものであっても構いません >>3。

文脈

[15] ダイジェスト認証の challenge で使うことができます。

処理

[9] クライアントは、同じ認証情報を適用できる URL の範囲を決定するために domain 引数の値を使うことができます。 指定された URL (を解決したもの) が接頭辞である URL は、同じ保護空間内として扱うことができます。 >>3

[13] できるというだけで、必須とはされていません。実際にどうクライアントが処理しているのかは不明です。 異なる起源に credentials を自動送信するのはセキュリティー上の問題かもしれません。[18] 接頭辞一致とだけ規定されていて、ディレクトリー単位などは考慮されないようです。 URL の正準化についても明言されていません。 http://foo.example と指定されていると http://foo.example.net も接頭辞一致してしまいますが、流石にそれは問題がありそうです。

[10] クライアントは、 domain 引数が指定されていないか空なら、 同じ起源の URL すべてが保護空間内とみなすべきです >>3。

[11] ただし、 Proxy-Authenticate: ヘッダーに指定されても無視しなければなりません。 常にプロキシ全体が保護空間となります。 >>3

歴史