共计 1310 个字符,预计需要花费 4 分钟才能阅读完成。
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 的原创文章,尽在:” 汪子熙 ”: