[403] 401 (Unauthorized) は、HTTP認証が必要であって、
要求に適切な credentials が含まれていなかったことを示す状態符号です。
[5] 401 は、要求に対象資源に対して妥当な認証の
credentials が含まれていなかったために要求を適用しなかったことを示す状態符号です
>>3。
[6] 要求が credentials を含んでいた場合には、 401
応答はその credentials に対する認可を拒んでいることを示します >>3。
[410] 401 応答を生成するサーバーは、
対象資源に適用される challenge を最低1つは含んだ
WWW-Authenticate: ヘッダーを送信しなければなりません
>>3, >>16, >>408, >>411, >>412, >>415, >>416, >>419, >>420。
[14] 401 応答の payload は、認証に失敗した理由などを記述した簡単な
HTML 文書とするのが一般的です。会員制サイトなどでは登録ページへのリンクを含めたりします。
[2] 起源鯖は、保護された資源に対する要求で credentials がなかったり、
非妥当な credentials (例えば誤ったパスワード) が指定されていたり、
不完全な credentials (例えば複数回の往復が必要な認証方式の途中の段階)
が指定されていたりする場合には、最低1つの (おそらくは新しい)
challenge が指定された WWW-Authenticate:
ヘッダーを含む 401 応答を送信するべきです >>1。
[17] PROPFIND 要求に対する 207
応答内の status 要素では、
適切な認証のもとでしか値を表示できないことを表すために使うことができます >>18。
[19] OAuth 1.0 の認証された要求が不適切なときに、 401
応答を返すべき場合があります。
[21] OAuth 2.0 で要求が不適切な時に、 401
を使える場合、使わなければならない場合があります。
[7] 利用者エージェントは、 credentials を含む要求に対して 401
応答が返された時、新しい Authorization:
ヘッダーを指定した要求を再度試みても構いません >>3。
[406] 認証を通って 202 などの成功を表す応答が返されると、
以後、HTTP URL が同じ階層 (ディレクトリー)
以下の要求には利用者エージェントが自動的に同じ認証情報を付加するので、
鯖側での合言葉の変更などで 401 が返されない限り、
利用者が再度認証情報を求められることはありません。
[407] 通常この認証情報の記憶は同一 Webブラウザー・セッション内に限られます。 一般的な Webブラウザーは認証情報をセッションを越えて保存しますが、 自動的には送信せず、必ずセッションの最初の1回は明示的に利用者に問い合わせる仕組みになっています。
[404] Webブラウザーをはじめとする対話的な HTTP 利用者エージェントは、普通、
HTTP要求に対して 401 応答が返されると、
利用者に名前と合言葉のような認証情報を問い合わせ、
それを含めて再度 HTTP要求を送信するようになっています。
[405] 入力された認証情報が不適当であった場合には再度 401 が返されますから、
Webブラウザーも再度利用者に入力を求め、以後これを繰り返します。
利用者が断念すると、 401 メッセージの内容をレンダリングします。
[418] 401 応答が以前の応答と同じ challenge
を含んでいる場合で、利用者エージェントが既に何度か認証を試みていた場合には、
応答に含まれている表現に診断情報があるのが普通ですから、
これを利用者に提示するべきです >>3, >>416。
[10] かつては 401 による認証情報の入力はモーダルダイアログとして実装するのが普通でした。そのために表示中のあるページで
401 が返されるとWebブラウザーのすべての機能が一旦使えなくなるという不便な状態でした。
[12] alert などのモーダルダイアログに少し遅れて10年代半ばにはタブに対してモーダルとなり、
他のタブの操作は妨害しないように改善されています。
[13] 素朴な実装方法だと XHR で次々に 401 を返す URL
を開き続ける方法で利用者を妨害し続けるブラクラを作ることができてしまいます。
alert などのモーダルダイアログと同様に、
キャンセル時に以後そのタブないし起源の 401
による認証ダイアログの表示を抑制するオプションが必要でしょう。
[24] 利用者エージェントは、 navigate の際に、
認識できる challenge を含まない 401 応答は
200 応答のように表示しなければなりません >>22。
[23] 利用者エージェントは、認識できる challenge を含む
401 応答であっても、 200
応答のように表示すると共にモーダルダイアログでない形でログインできるようにしても構いません
>>22。
[402] Firefox は POST 時や XHR で 401
が返された時の扱いが一部バグっているようです。 (詳しい再現条件はよくわからないのですが・・・。)
普通なら合言葉の入力ダイアログ箱が出るところなのですが、出なかったりもして、謎です。
[25] 最近の Firefox は、フレーム内の navigate で
401 に遭遇し、保存済みの credentials がないときは、
ダイアログを表示せずに 401 応答を表示するようです。
The request requires user authentication. The response
{1945} must{2068,2616} MUST include a WWW-Authenticate header field ({1945} Section 10.16section{2068} 14.46{2616} 14.47) containing a challenge applicable to the requested resource. The client{1945} may{2068,2616} MAY repeat the request with a suitable Authorization header field ({1945} Section 10.2{2068,2616} section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user{1945} should{2068,2616} SHOULD be presented the entity that was given in the response, since that entity{2616} might include relevant diagnostic information. HTTP access authentication is explained in{1945} may{2068} MAY{2616} "HTTP Authentication: Basic and Digest Access Authentication" [43] .{1945} Section 11{2068} section 11
要求は利用者認証を必要としています。応答は、要求された資源に適用可能な誰何を含んだ WWW-Authenticate
頭欄を含んでいなければなりません。クライアントは、適当な Authorization 頭欄と共に要求を繰り返しても構いません。
要求が既に Authorization 証明書を含んでいる場合、 401
応答はその証明書について認証が拒否されたことを示します。 401
応答が前の応答と同じ誰何を含んでおり、利用者エージェントが既に最低一度は認証を試みている時は、
応答に含まれている実体には関係する診断情報が含まれているかもしれませんから、 (訳注)利用者エージェントはこれを利用者に提示するべきです。
[421] RFC 7252 - The Constrained Application Protocol (CoAP) ( ( 版)) <http://tools.ietf.org/html/rfc7252#section-5.9.2.2>
[414] 起源鯖によって使われる 401 に対して、串によって使われる
407 もあります。
[422] RFC 2660 - The Secure HyperText Transfer Protocol ( ( 版)) <http://tools.ietf.org/html/rfc2660#section-5.2.1>
The main difference is that the RFC requires unauthenticated requests to be answered with 401 Unauthorized responses. In many places, this would disclose the existence of user data. Instead, the GitHub API responds with 404 Not Found. This may cause problems for HTTP libraries that assume a 401 Unauthorized response.
[29] Make navigate's resource handling more explicit ( (annevk著, )) <https://github.com/whatwg/html/commit/806bc62caaee78a696a6c929558a5b801cceeec4>
[30] Move 401/407 into the network realm (annevk著, ) <https://github.com/whatwg/fetch/commit/ec6f5ef5f99cb6b0dd6c701b49791810fb380b04>
[31] Make CORS-preflight fetches set the CORS flag (annevk著, ) <https://github.com/whatwg/fetch/commit/9334fcbd34dc17e4508582c9fdc57f20ba5b728e>