在HttpWatch的帮助下,我试图找出GMail如何实现Comet .
我使用两个帐户登录GMail,一个在IE中,另一个在Firefox中 . 在GMail中使用“WASSUP”等一些神奇的词语在GMail中聊天 . 然后,我注销两个GMail帐户,过滤任何http内容而不使用“WASSUP”字符串 . 结果显示哪个HTTP请求是流式传输通道 . (注意:我必须注销 . 否则,永无止境的HTTP不会在HttpWatch中显示内容 . )
结果很有趣 . 流通道的URL如下:
https:// mail / channel / bind?VER = 8&at = xn3j33vcvk39lkfq .....
毫无疑问,GMail使用IFRAME进行IE浏览 . Http内容以“ <html><body>
”开头 .
最初,我猜测GMail在Firefox中使用多部分XmlHttpRequest进行Comet . 令我惊讶的是,响应标头没有“multipart / x-mixed-replace”标头 . 响应标头如下:
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Date: Sat, 20 Mar 2010 01:52:39 GMT
X-Frame-Options: ALLOWALL
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
Server: GSE
X-XSS-Protection: 0
不幸的是,HttpWatch不会告诉HTTP请求是否来自XmlHttpRequest . 内容不是HTML而是JSON . 它看起来像是对XHR的响应,但是如果没有multipart / x-mixed-replace,这对Comet不起作用,对吗?
还有什么办法可以弄清楚GMail如何实现Comet?
Update: 经过进一步调查,我相信GMail以这种方式实现了Comet:1)在IE中,它使用了一个永远隐藏的iframe; 2)在Firefox中,它使用forever-XHR而不使用multipart / x-mixed-replace标头 . 客户端将在条件(readyState == 3)OR(readyState == 4)中响应 . 也就是说,处于交互状态和完整状态 .
1 回答
按this article,
本文的其余部分将详细介绍,包括对替代品的探索以及GMail选择的具体方案 .