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:

( )< > @ , ; : \ / [ ] ? = “
“
—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 消息，只是含义不同。