[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
応答を表示するようです。
[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>
[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>