req.get('content-type')
正常的 batch 操作，response 的 content-type 不應該返回 html 型別：
正確的 batch response，Content-Type 值應該是 multipart/mixed; boundary=batchresponse_後面跟一個 guid
success handler 即下圖的 fnSuccess, 被包裹在 wraHandler 裡。
content-type 不同的 response，對應有不同的 handler 來處理。
httpClient.request 如果執行出錯，會進入到 catch 分支，錯誤訊息：
invalid MIME part type
使用分號將 multipart/mixed 和 boundary 的具體值分隔開。
每種型別都有對應的 handler，由對應的 handler 呼叫 read 方法執行 response 的解析操作。
解析 batch 操作的響應：
在出錯情況下，從 Chrome 開發者工具 network 標籤頁裡下載 batch 響應到本地，和不出錯的場景比較，格式上沒有任何差異：
問題出在 batch response 的 header 裡的 Content-Type 欄位。
chrome 裡看到的 content-type 不是這個啊：
body 是 null，所以進不去 7884 行的 dispatchHandler 函式：
multipart/mixed MIME 訊息由不同資料型別的混合組成。 每個 body part 都由一個 boundary 劃定。 boundary 引數是一個文字字串，用於將訊息正文的一部分與另一部分割槽分開來。 所有邊界都以兩個連字元 hyphens (--) 開頭。 最後的邊界也以兩個連字元 (--) 結束。 邊界可以由除空格、控制字元或特殊字元之外的任何 ASCII 字元組成。
如果我們透過 batch 請求向伺服器傳送一個 word 文件，則 HTTP body payload 的例子如下：
Content-type: multipart/mixed;
boundary="Boundary_any ascii character except some of the following special characters:
<BR/> ( )< > @ , ; : \ / [ ] ? = "
"
--Boundary_any ASCII character, except some special characters below:
content-Type: text/plain;----
charset=iso-8859-1
Content-transfer-encoding: 7BIT
--Boundary_ASCII characters
Content-type: application/msword;
name="message.doc"
Content-Transfer-Encoding: base64
在 multipart 訊息正文的情況下，一個或多個不同的資料集組合在一個正文中，值為 multipart 的 Content-Type 欄位必須出現在 HTTP request entity 的頭部欄位中。正文部分在語法上類似於 RFC 822 訊息，只是含義不同。
更多Jerry的原創文章，盡在："汪子熙":
