[11] WWW-Authenticate: ヘッダーは、
当該対象資源へのアクセスに必要な認証についての情報を含む challenge
を指定するものです。
[5] WWW-Authenticate: ヘッダーは、
対象資源に適用できる認証方式(群)と認証引数を示します >>3。
[414] WWW-Authenticate: ヘッダーの値は、
1つ以上の challenge のリスト (#) です >>3, >>413, >>417。
[1] この欄は、読点で分離することで複数の誰何を併記できます。
ところが、他の同様の欄とは異なり、誰何自体が引数の分離のために読点を使ってしまっています。
auth-scheme があるので構文上曖昧性はないのですが、
このために (欄名に依存しない) 汎用の構文解析器で複数の誰何を分離することができません。
おそらくこのような困った仕様になった原因は太古の HTTP では読点とセミコロンが曖昧に使われていたときの名残でしょう。
[8] 実装によっては、複数の challenge の指定に対応していないことがあります。 鯖は複数の challenge の指定を避けるべきでしょう。
[407] 鯖は、 401 応答を生成する場合、
1つ以上の challenge を含む
WWW-Authenticate: ヘッダーを送信しなければなりません。
>>3, >>406, >>413, >>417, >>408, >>409, >>411, >>416。
[6] 鯖は、credentials を指定すると (あるいは他の credentials
に変更すると) 応答に影響するかもしれないことを示すため、
他の応答でも WWW-Authenticate:
ヘッダーを生成して構いません >>3。
[424] RFC 4559 は 200 でも WWW-Authenticate:
ヘッダーを用いるとしています。
[7] WWW-Authenticate: ヘッダーは複数指定できます >>3。
[410] プロキシは、転送の際に WWW-Authenticate:
ヘッダーを変更してはなりません >>3, >>409, >>412, >>419, >>17。
[421] OAuth 1.0 を使う場合、 auth-scheme が OAuth である
WWW-Authenticate: 欄を含めても構わない >>420 とされています。
[18] WWW-Authenticate: ヘッダーは、
要求に適切な credentials が含まれず認証に失敗した時に使います。
認証に成功した時のサーバーからクライアントへの情報伝達には、
Authentication-Info: ヘッダーが使われます。
The WWW-Authenticate response-header field
mustMUST be included in 401 (unauthorizedUnauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI.
WWW-Authenticate 応答頭欄は、
401 (未認証) 応答メッセージに含められなければなりません。
欄値は、最低一つの誰何で構成します。
誰何は、その Request-URI に適用可能な認証方式および引数を示します。
- WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
The HTTP access authentication process is described in
section 11{2616} "HTTP Authentication: Basic and Digest Access Authentication" [43] . User agentsare advised to take special care in parsing the WWW-Authenticate field valuemustMUSTif it{2616} as it might contains {1945,2068}more than one challenge, or if more than one WWW-Authenticate header field is provided,since the contents of a challenge may itself{2616} the contents of a challenge itself can contain a comma-separated list of authentication parameters.
HTTP 接続認証処理は RFC2617 で説明されています。
利用者エージェントは WWW-Authenticate 欄値を構文解析するに当たって特別の注意を払うように助言しておきます。
欄値は複数の誰何を含むかもしれませんし、
複数の WWW-Authenticate 頭欄が提供されているなら、
誰何の内容自体が認証引数群の読点分離並びを含むかもしれません。
[2] realm にセミコロンが含まれると、
(quoted-string にしているのに)
ClassicMozilla はセミコロン前でぶった切ってしまいます。
(そのくせ、引用開始の引用符はちゃんと省いて表示してくれる。)
(NN2, NC 4.01 で確認。)
WinIE1 ですらこんなことはありませんでした。
なんと、 Mosaic Netscape 0.9 は正しく処理します。
[402] フォームの提出先が基本認証の時の動作が変なブラウザーがありますね。
Gecko とか WinIE とか WebKit とか。最初必ず認証なしで試して、 401
なら再試行するところ、なぜか再試行しようとして接続を試みたままだったり。
Firefox だと最初の1回目だけ変なことがあって次からはうまくいくみたいですが。
リンク先が違うディレクトリだったりとかも関係してるっぽ。
Safari と Chrome の間でもなんかちがうな。。。
[405] 起源鯖ではなく、途中の串について行う認証のための
Proxy-Authenticate: 欄もあります。
Negotiateの項を参照。