[5] 407
は、串を使うためにHTTP認証が必要なことを示す状態符号です。
[4] 407
は、クライアントが串を使うために認証が必要なことを示す状態符号です
>>3。
401
は起源鯖が使うものですが、 407
は串が使うものです。 WWW-Authenticate:
/Authorization:
と Proxy-Authenticate:
/Proxy-Authorization:
と組み合わせて使うヘッダーも異なっています。[404] 串は 407
応答で対象資源に適用される
challenge を含む Proxy-Authenticate:
ヘッダーを送信しなければなりません >>3, >>9, >>402, >>405, >>410, >>411。
[2] 認証が必要な串は、要求で串についての credentials がなかったり、
非妥当な credentials (例えば誤ったパスワード) が指定されていたり、
不完全な credentials (例えば複数回の往復が必要な認証方式の途中の段階)
が指定されていたりする場合には、最低1つの (おそらくは新しい)
challenge が指定された Proxy-Authenticate:
ヘッダーを含む 407
応答を送信するべきです >>1。
[11] HTTP接続のどの応答でなければならないか、という規定はないようです。
普通はプロキシ全体に認証が必要ということで最初の要求に対する応答で使われるのでしょうが、
対象URLによって認証が必要だったり異なるcredentialsが必要だったりする場合には、
途中の要求に対する応答で 407
が返されることもあるかもしれません。
[6] クライアントは、 407
応答を受信した場合に新しい
Proxy-Authorization:
ヘッダーを含む要求を再度送信しても構いません
>>3。
[16] HTTPS 通信をプロキシ通過させようとして送信した
CONNECT
メソッドの要求に対して 407
応答 (やその他 200
以外の応答) が返された場合、その応答は、 HTTPS の応答ではありませんから、
取り扱いには注意が必要です。 >>13, >>19
[17] 例えば https://www.example.com/foo
へアクセスしようとしてプロキシが
407
を返したとしても、 https://www.example.com
の起源の応答としてスクリプトを実行などしてはなりません。
407
応答も信用できないとすると、プロキシ認証自体が危険ということになります。
プロキシとの接続自体が、素のHTTPではなく HTTPS となっているべきです。
HTTPS への移行が進み、多くの Webブラウザーは HTTPS
によるプロキシへの接続に対応しています。[14] Chrome は非プロキシから 407
応答を受信すると、
ネットワークエラー扱いにするようです。 (接続は閉じません。)
Firefox や IE は通常の応答としての処理を行います
(認証ダイアログは表示しません)。
[408] RFC 2069 は串で認証が必要な時に 401
を返すと書いていましたが、
同じ部分が RFC 2617 では 407
を返すと修正されています。
[13] 479880 – (CVE-2009-1836) Non-200 responses to proxy CONNECT requests lead to attacks on HTTPS ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=479880>
[19] Vulnerability Note VU#905344 - HTTP CONNECT and 407 Proxy Authentication Required messages are not integrity protected () <https://www.kb.cert.org/vuls/id/905344>
[15] Move 401/407 into the network realm (annevk著, ) <https://github.com/whatwg/fetch/commit/ec6f5ef5f99cb6b0dd6c701b49791810fb380b04>
401
と似ていますが、起源サーバーではなくプロキシが使います。