使える Proxy-Authenticate チャレンジがない HTTP 407

クライアントはステータス番号だけから認証方式を選択することはできません。プロキシの応答は、何を受け入れるかを示す必要があります。

HTTP では、407 を生成するプロキシが Proxy-Authenticate チャレンジを送ることが求められます。Basic サービスの簡単な例は次のとおりです。

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Office proxy"

数値ステータス、ヘッダー名、スキーム固有の構文はすべて重要です。本文に authentication という語を含むブランド付きのエラーページは、ヘッダーの代わりにはなりません。独自実装でも、ヘッダーの終端と本文のフレーミングを含む完全な HTTP 407 応答を送る必要があります。

このクライアントに届いた応答を確認する

秘密の値を取り除いたうえで、ステータスとチャレンジのフィールドを記録します。中間装置が応答を変換した可能性も、独自プロキシが無効なチャレンジを組み立てた可能性もあります。その証拠をプロキシ自身のトランザクションログと比較してください。

サービスが代わりに 405 や別のエラーを返す場合、独自クライアントの中でそのような応答をすべて 407 に付け替えてはいけません。実際のメソッドポリシーの失敗を隠したうえ、信頼できるスキーム交渉も得られないままになります。サービスの動作を修正するか、文書化されたサポート対象の認証経路を使用してください。

複数のチャレンジにも本物の HTTP パーサーが必要です。カンマはパラメーターやチャレンジを区切る可能性があり、ヘッダー全体を盲目的にカンマで分割すると引用符で囲まれた realm が壊れることがあります。連続した文字列置換ではなく、クライアントがサポートする認証実装を使用してください。

チャレンジが使えるようになって初めて、資格情報プロバイダーがアカウントを返さなかった理由を調べる意味が生まれます。