如何使用 Url Monikers 或其他方法在 IE 中更改 Accept-Encoding 标头？
我正在开发一个浏览器插件和服务器组件系统，它使用自定义编码类型传输内容。 现在我希望能够在服务器端检测客户端是否可以处理特殊编码，并希望使其与 HTTP 的通常工作方式保持一致，因此我想从浏览器插件中添加一个新的Accept-Encoding 请求标头中的编码。 即：
Accept-Encoding：gzip、deflate、myencoding
我尝试实现 IHttpNegotiate 并将其设置为 BeginningTransaction 中的附加标头，但它似乎要么忽略它，要么稍后被覆盖。
I'm developing a browser plugin and server component system that streams content with a custom encoding type. Now I would like to be able to detect on the server side whether the client can handle the special encoding, and would like to keep it consistent with the usual way things work with HTTP, so from the browser plugin I would like to add a new encoding in the Accept-Encoding request header. i.e.:
Accept-Encoding: gzip, deflate, myencoding
I have tried implementing IHttpNegotiate and setting it as an additional header in BeginningTransaction, but it seems to either ignore it or it gets overwritten later.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
请不要尝试这样做。 任何允许您修改 Accept-Encoding 标头（例如异步可插拔协议包装）的方法都必然是一种 hack，并且不会可靠地工作，因为 WinINET、代理等都对 Accept-Encoding 和 Content-Encoding 做出假设标头，并引入新方案将不可靠。
例如，我听说一种流行的代理会将未知编码视为 GZIP 并重写 Content-Encoding 标头作为响应； 显然这会破坏你的计划。
Please don't try to do this. Any approach that would allow you to modify the Accept-Encoding header (e.g. Asynchronous Pluggable Protocol wrapping) would necessarily be a hack, and will not work reliably because WinINET, proxies, etc, all make assumptions about the Accept-Encoding and Content-Encoding headers, and introducing a new scheme will not be reliable.
For instance, I've heard that one of the popular proxies will treat unknown encodings as GZIP and rewrite the Content-Encoding header in response; obviously that will break your scheme.