HTTP 客户端是否应该解析 HTTP 标头以响应错误 404 Not Found答案

【问题标题】：Should HTTP Client parse HTTP Headers in response with the error 404 Not FoundHTTP 客户端是否应该解析 HTTP 标头以响应错误 404 Not Found
【发布时间】：2012-10-02 04:41:00
【问题描述】：

如果收到带有错误 4xx 的 HTTP 响应，我找不到任何 RFC 或 HTTP 客户端行为标准。我知道 401、407 是解析 HTTP 标头时的示例，但是...

我有 OPTIONS 方法 (HTTP1.1) 的具体问题。服务器响应 401 Unauthorized，因此客户端尝试进行身份验证并重新发送带有身份验证的请求。之后响应出现错误 404 Not Found 并且 HTTP 标头填充了 Set-Cookie HTTP 标头。客户端使用 Apache Java HTTPClient/HTTPComponents，它会在响应中出现错误时忽略 HTTP 标头。

这个 HTTP Header 应该被客户端接受吗？我认为不应该，但我在 RFC 中找不到支持性引用。

【问题讨论】：

当您说“应该接受这个 HTTP 标头”时，您指的是 Set-Cookie 吗？在这种情况下，HTTP 规范是错误的地方；你需要参考 RFC 6265。
是的，在这种情况下，我指的是 Set-Cookie。表示希望对本案有一些一般性的建议。

标签： http header client

【解决方案1】：

RFC 2616 未指定应忽略任何标头，not for 404 responses 和 not for 4xx responses in general。

RFC 6265 允许客户端忽略 Set-Cookie 标头，但没有指定可能发生这种情况的情况；给出了一个例子，不包括你的情况：

用户代理可能希望阻止对“第三方”请求的响应从设置cookies

在您的情况下，由于您的服务器似乎使用 HTTP 基本访问身份验证，因此它似乎与 Set-Cookie 标头无关。在 HTTP 基本身份验证中，Authorization 标头由客户端随每个请求一起发送，因此不需要将状态保存在 cookie 中。

从您的问题中不清楚您是否有一个非常特定的 HTTP 服务器正在与之交谈，或者您是否正在实现一个通用的 HTTP 客户端，该客户端应该与您抛出的任何服务器一起工作。如果您遇到这样一种特殊情况，即您使用的 HTTP 服务器发送带有404 响应的状态，并且您需要遵守该状态才能与服务器通信，并且您无法控制服务器，那么它不管标准怎么说；您将遵守发送的状态，否则您将无法与服务器对话。

另一方面，如果您正在实现一个通用客户端并且需要它在不考虑远程服务器的情况下工作，那么您最好的选择是坚持使用RFC 1958：

发送时要严格，接收时要宽容。在发送到时，实现必须严格遵循规范网络，并容忍来自网络的错误输入。当在怀疑，静默丢弃错误输入，不返回错误除非规范要求，否则消息。

对我来说，这意味着无论状态代码如何，您都应该尊重收到的完整回复，除非您有客观原因使您无法这样做。我认为没有理由忽略该状态，即使它违反了标准（或者在这种情况下，是您对标准的个人看法，因为它没有说明接受或忽略该状态）。

更新：RFC 2617 (HTTP Authentication) 声明：

客户端应该假设所有路径都在或深于 Request-URI 的路径字段中的最后一个符号元素也是位于基本领域值指定的保护空间内当前的挑战。客户端可以抢先发送相应的 Authorization 标头，其中包含对资源的请求该空间没有收到来自服务器的另一个挑战。

如果服务器期望对一个 URL 进行 HTTP 身份验证，但对它下面的 URL 不接受它，则需要对它们进行单独的基于 cookie 的身份验证，这是高度不一致的。如果你的服务器实现有什么需要改变的，那就是协调所有资源的身份验证方案。

【讨论】：

这是一个很好的答案，除了结尾。 “发送时要严格，接收时要宽容”原则的概括是软件开发中最糟糕的建议之一：您只是鼓励远程方继续向您发送不合规的消息并得到远离它。然后你得到的是一个不完全遵循规范并且永远不会失败的软件，直到有一天该规范的另一个实现正确地遵循规范并且无法与不兼容的实现交互（这太宽容了） .
@Bruno 不幸的是，对于错误的远程实现几乎没有什么可做的。真的只有两个选择：忽略错误，用你可以处理的部分做你能做的；或将遥控器完全列入黑名单并假装它不存在。根据具体情况，任何一种选择都可能是正确的方法。您认为我的回答很糟糕，但这只是务实的。如果其他人需要与您交谈，您可能可以强制执行严格合规，但当您需要与您交谈时，您无能为力其他的，他们并不严格。
我不认为你的回答不好（只是最后的那个原则）。正如您所说，cookie 规范允许客户端忽略 Set-Cookie，这将使 Apache HTTP 客户端库在这方面符合 RFC 6265（和 2616）。在这里引用 RFC 1958 似乎无关紧要，因为 RFC 6265 说Set-Cookie 的接收者无论如何都可能忽略它。至于能否严格遵守，不幸的是，这取决于市场力量。即使您接受了不合规的消息，也不要假装它是有效的。这里的关键是丢弃错误的输入，而不是对其采取行动。
浏览器已经实施了多年的配置机制来忽略 cookie（第三方和第一方）。尽管如此，如果您将浏览器设置为忽略第一方 cookie，您的浏览体验几乎在所有情况下都会受到影响。如果您忽略第三方 cookie，降级可能不会那么明显，但仍然很明显。我们谈论的是 GUI 浏览器还是使用 HTTP 客户端库的自动化应用程序并不重要。如果你需要访问服务器来完成某事，你需要确保使用服务器的怪癖。
我们正在努力成为通用的WebDAV客户端。但是在这种情况下，客户端和服务器是由一家公司开发的，但不同的团队，所以我想找出问题应该由哪个团队解决。