在 HttpWatch 的帮助下，我试图弄清楚 GMail 是如何实现 Comet 的。
我使用两个帐户登录 GMail，一个在 IE 中，另一个在 Firefox 中。在 GMail 中使用诸如“WASSUP”之类的魔法词在 GTalk 中聊天。然后，我注销两个 GMail 帐户，过滤任何没有“WASSUP”字符串的 http 内容。结果显示哪个 HTTP 请求是流式传输通道。（注意：我必须注销。否则，永无止境的 HTTP 不会在 HttpWatch 中显示内容。）
结果很有趣。流通道的 URL 如下：
GMail 使用 IFRAME 在 IE 中做 Comet 也就不足为奇了。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 的吗？
更新： 经过进一步调查，我相信 GMail 以这种方式实现 Comet：1）在 IE 中，它使用永远隐藏的 iframe；2) 在 Firefox 中，它使用没有 multipart/x-mixed-replace 标头的 forever-XHR。客户端将响应条件 (readyState == 3) OR (readyState == 4)。即，处于交互状态和完成状态。