首页 文章

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

提问于
浏览 次
1

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

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

客户端是否应接受此HTTP标头？我相信它不应该，但我在RFC中找不到支持性引用 .

http header client

1 回答

  • 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：

    发送时要严格，接收时要宽容 . 实现必须在发送到网络时精确遵循规范，并容忍来自网络的错误输入 . 如有疑问，请静默丢弃错误输入，而不返回错误消息，除非规范要求这样做 .

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

    Update: RFC 2617 (HTTP Authentication)州：

    客户端应该假设所有在Request-URI的路径字段中最后一个符号元素深度处或更深的路径也在当前质询的Basic域值指定的保护空间内 . 客户端可以抢先发送相应的授权标头，其中包含该空间中的资源请求，而不接收来自服务器的另一个质询 .

    如果服务器期望对一个URL进行HTTP身份验证，但是对于它下面的URL不支持它，则需要对它们进行单独的基于cookie的身份验证，这是非常不一致的 . 如果在服务器实现中应该更改任何内容，则应该协调所有资源的身份验证方案 .

    回复于

相关问题