С помощью HttpWatch я попытался выяснить, как GMail реализует Comet.
Я вхожу в GMail с двумя учетными записями, одна в IE, а другая в Firefox. Общение в GTalk в GMail с волшебными словами вроде "WASSUP". Затем я выхожу из обеих учетных записей GMail, фильтрую любой http-контент без строки «WASSUP». Результат показывает, какой HTTP-запрос является потоковым каналом. (Примечание: мне нужно выйти из системы. В противном случае нескончаемый HTTP не будет отображать содержимое в HttpWatch.)
Результат интересный. URL-адрес для потокового канала выглядит так:
Нет ничего удивительного в том, что GMail выполняет Comet в IE с IFRAME. Содержимое HTTP начинается с «<html><body>».
Первоначально я догадывался, что GMail выполняет Comet в Firefox с помощью multipart XmlHttpRequest. К моему удивлению, в заголовке ответа нет заголовка 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, но это не сработает для Comet без multipart / x-mixed-replace, верно?
Есть ли еще способ выяснить, как GMail реализует Comet?
Обновление. После дальнейшего исследования я считаю, что GMail реализует Comet следующим образом: 1) в IE используется iframe, скрытый навсегда; 2) в Firefox он использует forever-XHR без заголовка multipart / x-mixed-replace. Клиент ответит в conditon (readyState == 3) OR (readyState == 4). То есть как в интерактивном, так и в завершенном состоянии.
