更改正在 iframe 中加载的页面的请求标头
我正在使用 Appweb 服务器（迷你 http 服务器），并在使用 https 打开网页时遇到问题。 页面被截断，当查看 HTTP 响应标头时，发现网络服务器正在以块的形式发送响应（传输编码集），这就是根本原因。 这似乎是网络服务器中的一个错误。
我再次构建了网络服务器，禁用了 Http 分块支持，发现页面加载正常。 该页面正在 iframe 内加载。
我不想对所有网页禁用 Http 分块，因为它可能会降低其他页面的性能。 因此，我想知道是否有一种方法可以为 iframe 中加载的页面设置自定义请求标头，以便我可以发送仅该网页不支持的 http 分块。
谢谢，
纳迦基兰
I am using Appweb server (mini http server) and facing an issue while opening a webpage using https. The page is getting truncated and when looked at HTTP response headers found that webserver is sending response in chunks (Transfer-Encoding set) and that is the root cause. It seems to be a bug in webserver.
I built webserver again disabling Http chunking support and found that the page is loading fine. This page is being loaded inside an iframe.
I don't want to disable Http chunking for all webpages as it may have degrade some performance for other pages. So, I want to know if there is a way to set the custom request headers for the page that is being loaded in an iframe so that i will send http chunking not supported for that webpage alone.
Thanks,
Naga Kiran
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
除非您分发浏览器，否则您将无法指定 IE/Firefox/Safari/等何时使用。 设置TE头。 您也许可以在处理标头之前在 Web 服务器的请求处理程序中注册回调，并删除 TE 标头，但是...
不幸的是，TE: 客户端标头只能出现在也具有 Connect: 标头的请求中，这通常仅位于管道的开头和结尾（请参阅 rfc2616 ），这意味着如果浏览器已经重用了您不希望分块的页面的连接，那么您就不走运了。
黑客：您可以考虑嵌入禁用分块的网络服务器的第二个实例，并仅从那里提供问题页面。 显然，这需要在不同的虚拟主机或端口上运行服务器。
如果您的供应商能够修复错误，这是最理想的，但我知道您无法选择时间:-)
Unless you're distributing the browser, you won't be able to dictate when IE/Firefox/Safari/etc. set the TE header. You may be able to register a callback in your webserver's request handler before headers are processed, and remove the TE header, but...
Unfortunately, the TE: client header only has to appear in requests that also have the Connect: header, which are usually only at the beginning and end of the pipeline (see rfc2616), which means that if a browser is already reusing the connection for the page you don't want chunked, then you're out of luck.
A hack: you may consider embedding a second instance of the webserver that has chunking disabled and serve only the problem page from there. Obviously this requires running the server on a different vhost or port.
It's most ideal if your vendor can just fix the bug, but I know you don't get to pick the timing on that :-)