What technique does Gmail employ for its Comet functionality?

Other Questions Gmail
1

I’m trying to dig into how Gmail manages its real-time messaging through Comet. Using a network analysis tool, I examined the HTTP traffic while chatting in Gmail.

To do this, I logged into Gmail with two different accounts using Internet Explorer and Firefox. During a chat in Google Talk, I used the phrase “WASSUP” and then logged out of both accounts. By filtering the HTTP requests that did not contain the string “WASSUP”, I was able to identify which requests were related to the streaming channel.

The streaming URL seemed to resemble something like:
https://mail/channel/bind?VER=8&at=xn3j33vcvk39lkfq

It’s clear that Gmail’s Comet implementation in Internet Explorer utilizes an IFRAME. The content starts with HTML tags like <html><body>.

I had assumed Gmail would leverage multipart XmlHttpRequest in Firefox, but surprisingly, the response didn’t have the multipart/x-mixed-replace header. The headers were:

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 network tool didn’t confirm if the requests were made via XmlHttpRequest. The data returned was in JSON format, which suggests it could be related to XHR. However, I’m not sure how this can work for Comet without the necessary multipart headers.

Is there another method to analyze how Gmail implements Comet dynamics? I’m especially interested in how it differs across browsers.

2

gmail’s not into multipart comet, it relies on long polling. they keep that xhr connection alive n send chunked data as it comes. hence, the transfer-encoding: chunked but no multipart headers. it performs well on various browsers without iframe issues.

3

I’ve implemented something similar before, and Gmail uses a hybrid approach that depends on what your browser can handle. That chunked transfer encoding is the magic - they’re streaming data bit by bit over one persistent connection instead of traditional multipart responses. The JSON format tells me they’re using XHR with readyState monitoring to handle chunks as they come in. It’s a clever workaround for browser limitations that keeps everything running smoothly. Want to dig deeper? Fire up Chrome DevTools network tab and turn on preserve log - you’ll see way more connection details and timing info than basic network analyzers show.

4

From what I’ve seen, Gmail uses HTTP streaming with chunked encoding, not multipart Comet. You don’t need multipart headers because the response gets processed piece by piece through JavaScript callbacks tied to XHR readyState changes. Each chunk has complete JSON messages that get parsed as they come in. The iframe fallback for IE is crucial since older versions can’t handle streaming XHR properly. Want to see this in action? Open your browser’s debugger during a chat session and watch the response handlers fire as chunks arrive - you’ll see it’s streaming, not polling.