HTTP规范在主体中非常明确，消息接收者可以安全地忽略未知头文件。
要求客户端和服务器必须实现由其声明一致性的HTTP版本指定的所有头;即声明HTTP / 1.1功能的服务器不得忽略有效的HTTP / 1.1标头，因为这意味着它错误地宣传其功能，客户端会收到意外的响应。
这个原则很简单，非常实用;它允许添加新的头文件，这些头文件将优化来自理解它们的服务器的响应，同时允许不理解它们的服务器仍然提供可能对客户端有用的响应。
通过阅读规范我似乎无法澄清的一点是如何处理服务器已知和支持但客户端错误使用的标头。
例如，Server:，Retry-After:，Location:等标题都是严格的响应标头。因为这些标题作为请求的一部分被接收，似乎表明客户端和服务器之间存在一些严重的误解。
同样，If-None-Match:和If-Modified-Since:，Host:标头以及Accept:，Accept-Charset:标头等条件标头都是严格的请求标头;它们在响应中的存在同样似乎表明发送方正在提交协议错误。
最后，并非所有邮件都包含有效内容，因此content-language:和content-range:等实体标头的存在似乎也是错误的。
无效上下文中的已知标头是否应被视为协议错误？实际上，这需要来自服务器的4xx响应，并要求客户认为响应格式不正确。
或者，这些标题是否应该以与未知标题相同的方式被忽略？
我无法找到任何关于此的讨论，因此我试图了解现有Web服务器的行为方式。一些小提琴手向谷歌和维基百科的请求似乎表明他们两个：
答案 0 :(得分：1)
无效上下文中的已知标头是否应被视为协议错误？
没有。除非他们使请求完全无法理解或无法满足。如果可以忽略格式错误或不合适的标题，请执行此操作。
以下是RFC2616（HTTP / 1.1规范）的引用：
19.3容忍申请
虽然本文档规定了生成HTTP / 1.1消息的要求，但并非所有应用程序的实现都是正确的。因此，我们建议，只要可以明确地解释这些偏差，操作应用就能容忍偏差。
无论如何，请求中的响应头（反之亦然）应始终被视为未知头。您无法确定将来的HTTP版本是否允许以这种方式使用它们。