Major In protocol spec v4.01, section 11.7.7.1 Multipart Batch Request Body example...
After:
Content-Length: ###
there is a single blank line (which is required to terminate the HTTP headers).
Now RFC2046 states:
"The boundary delimiter MUST occur at the beginning of a line, i.e.,
following a CRLF, and the initial CRLF is considered to be attached
to the boundary delimiter line rather than part of the preceding
part. "
So after the Content-Length: ### in the example should appear two blank lines (i.e. two CRLF pairs). The second CRLF pair will be the beginning of the first boundary occurrence.
Similarly after:
Content-Type: multipart/mixed; boundary=changeset_77162fcd-b8da-41ac-a9f8-9357efbbd
there should be another blank line (CRLF pair), since one is required to end the headers and one is required to begin the boundary.
and we must interpret that the CRLF pair after each of the two <JSON representation of XXX> occurrences in the example actually belongs to the boundary, not the JSON encoding.
Although the examples are non-normative, they of course still need to be corrected.
The example shows two adjacent lines:
-changeset_77162fcd-b8da-41ac-a9f8-9357efbbd-
--batch_36522ad7-fc75-4b56-8c71-56071383e77b
which also should have a blank line between them.
Similar issues of missing CRLF pairs are apparent in all of the other batch request/response examples.
And even missing in the multipart/alternative example in RFC2046 (see page 26 in https://tools.ietf.org/html/rfc2046).
Given that these examples appear in similar form in OData 4.0 spec as well as OData 4.01, there appears to be considerable scope for interoperability issues if existing 4.0 agents (which may be coded in accordance with the examples) are fixed in accordance with the RFC2046 prose.
Examples in OData 2.0 spec are also missing a few CRLF pairs.