エラー4xxでHTTP応答を受け取った場合の、RFCまたはHTTPクライアントの動作の標準が見つかりません。401、407がHTTPヘッダーを解析するときの例であることは知っていますが、...
OPTIONSメソッド（HTTP1.1）の具体的な問題があります。サーバーは401Unauthorizedと応答するため、クライアントは認証を試み、認証を使用して要求を再送信します。その後、応答にはエラー404 Not Foundがあり、HTTPヘッダーはSet-CookieHTTPヘッダーで埋められます。クライアントはApacheJavaHTTPClient / HTTPComponentsを使用します。これは、応答でエラーが発生した場合にHTTPヘッダーを無視します。
このHTTPヘッダーはクライアントによって受け入れられるべきですか？そうすべきではないと思いますが、RFCで裏付けとなる引用を見つけることができません。
RFC 2616 では、404 応答や一般的な 4xx 応答に対して、ヘッダーを無視することは指定されていません。
RFC 6265では、クライアントがヘッダーを無視することを許可Set-Cookieしていますが、それが発生する状況については指定していません。あなたのケースをカバーしていない単一の例が示されています：
ユーザーエージェントは、「サードパーティ」のリクエストへの応答をブロックして、Cookie を設定することを希望する場合があります。
Set-Cookieあなたの場合、サーバーは HTTP 基本アクセス認証を使用しているように見えるため、ヘッダーには関係ないようです。HTTP 基本認証では、すべてAuthorizationの要求でクライアントによってヘッダーが送信されるため、Cookie に状態を保持する必要はありません。
あなたが話している非常に特定のHTTPサーバーがあるかどうか、またはあなたがそれを投げるどんなサーバーでも動作するはずの一般的なHTTPクライアントを実装しているかどうかは、あなたの質問からは明らかではありません。使用している HTTP サーバーが応答で状態を送信するような特定のケースがあり404、サーバーと通信するためにその状態を尊重する必要があり、サーバーを制御できない場合、それは問題ではありません。規格の内容; 送信された状態を尊重するか、サーバーと通信できなくなります。
一方、一般的なクライアントを実装していて、リモートサーバーに関係なく動作する必要がある場合は、RFC 1958に固執するのが最善の策です。
送信するときは厳密に、受信するときは寛大にします。実装は、ネットワークに送信するときに仕様に正確に従う必要があり、ネットワークからの誤った入力を許容する必要があります。疑わしい場合は、仕様で要求されている場合を除き、エラー メッセージを返さずに、誤った入力を黙って破棄します。
これは、ステータス コードに関係なく、受け取った完全な応答を尊重する必要があることを意味します。客観的な理由でそうすることが不可能な場合を除きます。状態が標準に違反している場合でも、状態を無視する理由はわかりません (または、この場合、状態を受け入れるか無視するかについて何も述べていないため、標準に対する個人的な認識です)。
更新: RFC 2617 (HTTP 認証)には次のように記載されています。
クライアントは、Request-URI のパス フィールドの最後のシンボリック要素の深さ以上のすべてのパスも、現在のチャレンジの基本領域値によって指定された保護空間内にあると想定する必要があります。クライアントは、サーバーから別のチャレンジを受信することなく、そのスペース内のリソースに対する要求とともに、対応する Authorization ヘッダーをプリエンプティブに送信できます。
サーバーが 1 つの URL に対して HTTP 認証を期待しているが、その下の URL に対してはそれを受け入れず、別の Cookie ベースの認証が必要な場合、これは非常に一貫性がありません。サーバーの実装で何かを変更する必要がある場合は、すべてのリソースの認証方式を調和させる必要があります。