为什么 XMLHttpRequest 规范阻止设置 Accept-Encoding 标头？答案

【问题标题】：Why does the XMLHttpRequest spec prevent setting the Accept-Encoding header?为什么 XMLHttpRequest 规范阻止设置 Accept-Encoding 标头？
【发布时间】：2014-04-17 05:11:10
【问题描述】：

今天，我想利用Accept-Encoding 标头请求base64 格式的图像。快来了解一下，XMLHttpRequest 规范会阻止设置该标头！

http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader()-method

注意：上述标头由用户代理控制，以使其控制传输的这些方面。这在一定程度上保证了数据的完整性。不允许将以 Sec- 开头的标头名称设置为允许生成新标头，这些标头保证不会来自 XMLHttpRequest。

他们到底为什么要编写这样的规范？如果没有指定默认值（例如gzip,deflate,sdch），浏览器会更有意义。

【问题讨论】：

标签： ajax http-headers xmlhttprequest w3c http-accept-encoding

【解决方案1】：

他们到底为什么要编写这样的规范？

一句话：懒惰。

为什么要为每个可能的标头添加额外的语义来描述安全可预测的浏览器行为，而这些标头只能由像我们这样的少数人使用，而他们可以在一个段落中声明所有禁止的标头。

【讨论】：

【解决方案2】：

浏览器负责接受和处理响应。操纵您的 XHR 说它接受 gzip 是没有多大意义的，例如，当您无法对它做任何事情时。您可以设置自定义标头值吗？

【讨论】：

谢谢！我希望有更好的理由，但我认为这是有道理的。
如果浏览器支持的编码与脚本的要求不兼容，这是非常有意义的......例如，如果 gzip 是，则不发送内容长度（即使在 HTTP HEAD 请求上）包含在 Accept-Encoding... 中，因此在我找到一个方便的解决方法之前，我的脚本将毫无用处。在这种情况下，我对 HTTP HEAD 的无用感到惊讶。
^ 这正是我现在遇到的问题。 :(
问题是服务器有时行为不端，认为内容不是 gzip，然后设置 Content-Encoding:gzip 标头，然后浏览器错误地“负责处理响应”解压它会导致错误