关于sap:SAP-UI5-框架是如何执行-batch-请求的单步调试

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的原创文章，尽在："汪子熙":