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