fas*_*xes 5 streaming iframe comet xmlhttprequest
我知道我可能应该使用 WebSockets 或服务器端事件，但是涉及将分块数据从服务器写入iFrame或作为对 的响应的 Comet Streaming 技术发生了xmlHttpRequest什么？我偶然发现了多个演示，但它们都不再按预期工作，而且由于这种类型的流媒体上的大部分材料都很旧，我想知道它在 2015 年是否仍然可行？
为了清楚起见，我指的是 Comet 技术，其中服务器使用分块传输编码即时刷新新数据来保持连接打开。浏览器中的增量渲染应该可以使这些数据可用，无论是在iFrame（例如“Forever iFrame”）的情况下还是通过在返回时读取对象的responseText属性（例如“XHR流”）。然而，所有浏览器似乎都会缓冲数据直到连接关闭，无论我在开始发送真实数据之前添加了多少虚假的前导码。另外，我指的不是set to仅适用于 Firefox的特殊情况，而是一种似乎在几年前适用于大多数浏览器的方法。xmlHttpRequestreadyState3Content-Typemultipart/x-mixed-replace
有谁知道当前的浏览器行为是否已经淘汰了这些 Comet 流技术？
示例演示：
responseText通过xmlHttpRequest对象轮询负载：
http://ajaxify.com/run/streaming/xmlHttpRequest/countdown/ http://ajaxify.com/run/streaming/xmlHttpRequest/
常规页面加载缓慢，增量渲染不适合我：
http://ajaxify.com/run/streaming/
iFrame缓慢iFrame加载时轮询内容：
http://ajaxify.com/run/streaming/xmlHttpRequest/iframe/
这些演示不使用分块传输编码，但产生的行为是相同的，即不发生增量渲染。
关于彗星流的文章：
http://cometdaily.com/2007/11/05/the-forever-frame-technique/
短版结论：
所有 Comet 技术仍然有效，但是，在我的情况下，防病毒软件以不可预见的方式阻碍了事情的发展，因此请确保在不同的计算机和安全模式下进行测试，以确保它是否不起作用！
| 归档时间： |
|
| 查看次数： |
500 次 |
| 最近记录： |