我找不到任何 RFC 或 HTTP 客户端行为标准，以防它收到带有错误 4xx 的 HTTP 响应。我知道 401、407 是解析 HTTP 标头时的示例，但是...
我有 OPTIONS 方法（HTTP1.1）的具体问题。服务器响应 401 Unauthorized，因此客户端尝试进行身份验证并重新发送带有身份验证的请求。之后响应出现错误 404 Not Found 并且 HTTP 标头填充了 Set-Cookie HTTP 标头。客户端使用 Apache Java HTTPClient/HTTPComponents，它会在响应中出现错误时忽略 HTTP 标头。
客户端应该接受这个 HTTP Header 吗？我认为不应该，但我在 RFC 中找不到支持性的引用。
RFC 2616 未指定应忽略任何标头，对于 404 响应和一般的 4xx 响应也不应如此。
RFC 6265允许客户端忽略Set-Cookie标头，但没有指定可能发生的情况；给出了一个例子，不包括你的情况：
用户代理可能希望阻止对“第三方”请求的响应设置 cookie
在您的情况下，由于您的服务器似乎使用 HTTP 基本访问身份验证，因此它似乎与Set-Cookie标头无关。在 HTTP 基本身份验证中，Authorization客户端会随每个请求发送标头，因此不需要将状态保存在 cookie 中。
从您的问题中不清楚您是否有一个非常特定的 HTTP 服务器正在与之交谈，或者您是否正在实现一个通用的 HTTP 客户端，该客户端应该与您抛出的任何服务器一起工作。如果您有这样一个特定情况，即您使用的 HTTP 服务器发送带有404响应的状态，并且您需要遵守该状态才能与服务器通信，并且您无法控制服务器，那么没关系标准是怎么说的；您将遵守发送的状态，否则您将无法与服务器交谈。
另一方面，如果您正在实现一个通用客户端并且无论远程服务器如何都需要它工作，那么您最好的选择是坚持RFC 1958：
发送时要严格，接收时要宽容。在发送到网络时，实现必须精确地遵循规范，并容忍来自网络的错误输入。如有疑问，请静默丢弃错误输入，除非规范要求，否则不返回错误消息。
对我来说，这意味着无论状态代码如何，您都应该尊重收到的全部回复，除非您有客观原因使您无法这样做。我认为没有理由忽略该状态，即使它违反了标准（或者在这种情况下，是您对标准的个人看法，因为它没有说明接受或忽略该状态）。
更新： RFC 2617（HTTP 身份验证）状态：
客户端应该假设所有在请求 URI 的路径字段中的最后一个符号元素的深度或更深的路径也在当前挑战的基本领域值指定的保护空间内。客户端可以抢先发送相应的授权标头以及对该空间中资源的请求，而无需收到来自服务器的另一个挑战。
如果服务器期望对一个 URL 进行 HTTP 身份验证，但对它下面的 URL 不接受它，则需要对它们进行单独的基于 cookie 的身份验证，这是高度不一致的。如果您的服务器实现中需要更改任何内容，则应该是协调所有资源的身份验证方案。