How the SAP UI5 framework performs single-step debugging of batch requests

req.get('content-type')

For normal batch operations, content-type of the response should not return the html type:

Correct batch response, Content-Type value should be multipart/mixed; boundary=batchresponse_ followed by a guid


The success handler is fnSuccess in the figure below, which is wrapped in wraHandler .

Different responses of content-type correspond to different handlers.

httpClient.request If there is an error in execution, it will enter the catch branch, the error message:

invalid MIME part type

Use a semicolon to separate the specific values of multipart/mixed and boundary .

Each type has a corresponding handler, and the corresponding handler calls the read method to perform the parsing operation of the response.


Parse the response of the batch operation:


In the case of an error, download the batch response from the Chrome DevTools network tab to the local, and there is no difference in the format compared to the error-free scenario:


The problem lies in the Content-Type field in the header of the batch response.

The content-type seen in chrome is not this:


body is null, so the function 7884 in line dispatchHandler cannot be entered:


multipart/mixed MIME messages consist of a mix of different data types. Each body part is delimited by a boundary . boundary parameter is a text string used to distinguish one part of the message body from another. All boundaries begin with two hyphens hyphens (--). The final boundary also ends with two hyphens (--). Boundaries can consist of any ASCII characters except spaces, control characters, or special characters.

If we send a word document to the server via a batch request, an example of the HTTP body payload is as follows:

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

In the case of a multipart message body, where one or more different datasets are combined in one body, the Content-Type field with the value multipart MUST appear in the header field of the HTTP request entity. The body part is syntactically similar to an RFC 822 message, but with a different meaning.

More Jerry's original articles, all in: "Wang Zixi":