[5] 407 は、串を使うためにHTTP認証が必要なことを示す状態符号です。

[12] 401 と似ていますが、起源サーバーではなくプロキシが使います。

仕様書

意味

[4] 407 は、クライアントが串を使うために認証が必要なことを示す状態符号です >>3。

[8] 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 が返されることもあるかもしれません。

処理

[10] HTTP認証も参照。

[6] クライアントは、 407 応答を受信した場合に新しい Proxy-Authorization: ヘッダーを含む要求を再度送信しても構いません >>3。

[16] HTTPS 通信をプロキシ通過させようとして送信した CONNECT メソッドの要求に対して 407 応答 (やその他 200 以外の応答) が返された場合、その応答は、 HTTPS の応答ではありませんから、 取り扱いには注意が必要です。 >>13, >>19

[17] 例えば https://www.example.com/foo へアクセスしようとしてプロキシが 407 を返したとしても、 https://www.example.com の起源の応答としてスクリプトを実行などしてはなりません。

[18] 悪意あるプロキシの場合や、プロキシとクライアントとの間で改竄された場合に危険です。 そうでなくても、サーバーではなくプロキシの応答なのですから、 https://www.example.com を起源とするのは誤りです。[20] 407 応答も信用できないとすると、プロキシ認証自体が危険ということになります。 プロキシとの接続自体が、素のHTTPではなく HTTPS となっているべきです。 HTTPS への移行が進み、多くの Webブラウザーは HTTPS によるプロキシへの接続に対応しています。

[14] Chrome は非プロキシから 407 応答を受信すると、 ネットワークエラー扱いにするようです。 (接続は閉じません。) Firefox や IE は通常の応答としての処理を行います (認証ダイアログは表示しません)。

歴史

RFC 第2世代

  • [402] RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2068#section-10.4.8
  • [407] RFC 2069 - An Extension to HTTP : Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2069#section-2.5

RFC 第3世代

  • [405] RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2616#section-10.4.8
  • [410] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2617#section-1.2
  • [411] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2617#page-4
  • [409] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2617#section-3.6
[403] RFC 2068 & 2616 (HTTP/1.1) 10.4.8 407 Proxy Authentication Required

This code is similar to 401 (Unauthorized), but indicates that the client MUST must first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field (section 14.33) containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field (section 14.34). HTTP access authentication is explained in section 11 "HTTP Authentication: Basic and Digest Access Authentication" [43] .

この符号は、 401 (認証されていません) と同様ですが、 クライアントはまず串について認証しなければならないことを示します。 串は要求された資源について串に適用可能な誰何を含んだ Proxy-Authenticate 頭欄を返さなければなりません。 クライアントは、適当な Proxy-Authorization 頭欄をつけて要求を繰り返しても構いません。

[408] RFC 2069 は串で認証が必要な時に 401 を返すと書いていましたが、 同じ部分が RFC 2617 では 407 を返すと修正されています。

元々は 401 を使う案だったのが、別の状態符号を使った方が良いとなったのでしょう。

RFC 第4世代

  • [7] RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication ( 版) https://tools.ietf.org/html/rfc7235#section-3.2

[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