115登錄頁的long polling在chrome裡面為什麼看不到返回結果？

01-25

115的這種long polling是怎麼做的，看不到返回的結果，每次都是空，但是微信的http://wx.qq.com的二維碼登錄可以看到返回結果，

例如超時的408.在手機上掃描成功，確認登錄是201
115這個是怎麼做的啊，有沒有人來分析下？

不是 「看不到返回的結果，每次都是空」，這個請求其實是有 response body 的。

1. 首先我們用 wireshark 抓包可以看到這個 /r?VER=2*** 這個 comet request 的 response 是 gzip chunked 模式，把因此我們把所有的 chunk 找出來

2. 然後我們在 wireshark 裡面把各個 chunk 的位元組取出來，按照 chunked encoding 格式拼起來，中間涉及到換行分隔符、長度控制字元等等，略去不表，有興趣的同學自行參閱 spec

為了方便讀者閱讀，header 以純文本顯示，body 以 hex 格式顯示

HTTP/1.1 200 OK Server: nginx Date: Wed, 04 May 2016 08:09:18 GMT Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Connection: close Cache-Control: no-cache, must-revalidate Content-Encoding: gzip

1f:8b:08:00:00:00:00:00:00:03:52:50:18:05:a3:21:30: 1a:02:23:35:04:00:00:00:00:ff:ff:03:00:8d:c3:d7:24: 00:04:00:00

3. 我們把這段 body hex 複製出來，填到 hxd 里去保存成一個 body.gz 文件

4. 用 7zip 解壓這個文件，得到其內容：1024 個空格（%20）。。

最後，其實並不需要這麼麻煩，Chrome devtools 裡面也能看到最後的 response body 就是很多個空格，只不過題主看不見就以為是空響應，我們拿滑鼠選擇一下。

話又說回來了， comet 只是實現推送的一種方式，在此之上，怎麼表示用戶已登錄/未登錄，這就完全是程序員自己選擇的自由了，題主不必糾結這兩個網站這些在細節的差異，鑽研一下 HTTP 協議本身可能會更有幫助。

參考文獻：

HTTP chunked encoding spec: RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1

課後作業：

我還用 Node.js 的核心模塊寫了一個小爬蟲，把這個響應的 buffer 抓了一下，在這裡就把這個作為作業吧（要求用且只用 Node.js 核心模塊，不使用第三方模塊），有興趣的同學可以自己試一下，有助於加深對 Node.js HTTP/zlib 等模塊的理解。

# node 115/index.js Wed May 04 2016 16:48:04 GMT+0800 (中國標準時間) Start request Wed May 04 2016 16:48:04 GMT+0800 (中國標準時間) Response 200 Wed May 04 2016 16:48:04 GMT+0800 (中國標準時間) Response headers: { "server": "nginx", "date": "Wed, 04 May 2016 08:47:58 GMT", "content-type": "text/html; charset=utf-8", "transfer-encoding": "chunked", "connection": "close", "cache-control": "no-cache, must-revalidate", "content-encoding": "gzip" } Wed May 04 2016 16:48:04 GMT+0800 (中國標準時間) readable & Wed May 04 2016 16:49:04 GMT+0800 (中國標準時間) readable & Wed May 04 2016 16:49:04 GMT+0800 (中國標準時間) end & Wed May 04 2016 16:49:04 GMT+0800 (中國標準時間) gunzip Wed May 04 2016 16:49:04 GMT+0800 (中國標準時間) content &