With the help of HttpWatch, I tried to figure out how GMail implements Comet.
I login in to GMail with two accounts, one in IE and the other in Firefox. Chatting in GTalk in GMail with some magic words like "WASSUP". Then, I logoff both GMail accounts, filter any http content without "WASSUP" string. The result shows which HTTP request is the streaming channel. (Note: I have to logoff. Otherwise, never-ending HTTP would not show content in HttpWatch.)
The result is interesting. The URL for stream channel is like:
https://mail/channel/bind?VER=8&at=xn3j33vcvk39lkfq.....
There is no surprise that GMail do Comet in IE with IFRAME. The Http content starts with "<html><body>".
Originally, I guessed that GMail does Comet in Firefox with multipart XmlHttpRequest. To my surprise, the response header doesn't have "multipart/x-mixed-replace" header. The response headers are as below:
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
Unfortunately, the HttpWatch doesn't tell whether a HTTP request is from XmlHttpRequest or not. The content is not HTML but JSON. It looks like a response for XHR, but that would not work for Comet without multipart/x-mixed-replace, right?
Is there any way else to figure out how GMail implements Comet?
Update: After further investigation, I believe GMail implements Comet this way: 1) in IE, it use a forever-hidden-iframe; 2) in Firefox, it use forever-XHR without multipart/x-mixed-replace header. The client will response in conditon (readyState == 3) OR (readyState == 4). That is, in both interactive state and complete state.