HttpWatch の助けを借りて、GMail がどのように Comet を実装しているかを理解しようとしました。
IE と Firefox の 2 つのアカウントで GMail にログインします。「WASSUP」などの魔法の言葉を使って、GMail の GTalk でチャットします。次に、両方の GMail アカウントをログオフし、"WASSUP" 文字列のない http コンテンツをフィルター処理します。結果は、どの HTTP 要求がストリーミング チャネルであるかを示します。(注: ログオフする必要があります。そうしないと、終わりのない HTTP が HttpWatch にコンテンツを表示しません。)
結果は興味深いものです。ストリーム チャンネルの URL は次のようになります。
GMail が IE で IFRAME を使用して Comet を実行するのは当然のことです。HTTP コンテンツは " <html><body>
" で始まります。
当初、GMail はマルチパート XmlHttpRequest を使用して Firefox で 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 に対する応答のように見えますが、comet では multipart/x-mixed-replace がなければ機能しませんよね?
GMail が Comet を実装する方法を理解する方法は他にありますか?
更新: さらに調査した結果、GMail は Comet を次のように実装していると思います。1) IE では、永久に非表示の iframe を使用します。2) Firefox では、multipart/x-mixed-replace ヘッダーなしで、forever-XHR を使用します。クライアントは、状態 (readyState == 3) または (readyState == 4) で応答します。つまり、インタラクティブな状態と完全な状態の両方です。