CODEWITHSUNDEEP
httpbinarymultipartw3c
slartidan
slartidan

Reputation: 21576

Can a multi-part message contain raw binary content?

I want to transfer binary content via HTTP. I have doubts, whether sending a "multi-part" body consisting of the binaries and a short meta-data content is a good idea.

Can I send binary content in a multi-part message, without having to convert it (i.e. as BASE64)?

The RFC1341 specification does not seem to forbid it - but a non-escaped binary content could coincidentally contain the encapsulation boundary, couldn't it?

I wanted to see the data in my chrome's developer toolset - but the interesting part is not displayed.

Upvotes: 1

Views: 114

Answers (2)

Sandra Rossi
Sandra Rossi

Reputation: 13629

A multipart message can mix text and binary multipart entities e.g. one text and one JPEG image:

...
Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p

--gc0p4Jq0M2Yt08j34c0p
Content-Type: text/plain; charset=US-ASCII

<any text encoded in US-ASCII>
--gc0p4Jq0M2Yt08j34c0p
Content-Type: image/jpeg

<binary JPEG data>
--gc0p4Jq0M2Yt08j34c0p--

NB: no problem to have bytes directly in the message (binary JPEG data).

Concerning your doubt "but a non-escaped binary content could coincidentally contain the encapsulation boundary, couldn't it?", it's answered in the RFC2046:

The boundary delimiter MUST NOT appear inside any of the encapsulated parts, on a line by itself or as the prefix of any line. This implies that it is crucial that the composing agent be able to choose and specify a unique boundary parameter value that does not contain the boundary parameter value of an enclosing multipart as a prefix.

Because boundary delimiters must not appear in the body parts being encapsulated, a user agent must exercise care to choose a unique boundary parameter value. The boundary parameter value in the example above could have been the result of an algorithm designed to produce boundary delimiters with a very low probability of already existing in the data to be encapsulated without having to prescan the data. Alternate algorithms might result in more "readable" boundary delimiters for a recipient with an old user agent, but would require more attention to the possibility that the boundary delimiter might appear at the beginning of some line in the encapsulated part.

Upvotes: 0

Alexis Wilke
Alexis Wilke

Reputation: 20731

Clearly, yes. That's how most multi-Range requests are answered.

The size start and end positions defined in the Content-Range are used to calculate the size to read from the incoming data so it can really be absolutely anything, it just needs to be the exact right size (even when it is just text!)

Further, the content can be compressed. I'm not sure how each browser support sub-part compression, though.

Of course, you should have a Content-Type describing the content of the part anyway.

For example:

--<boundary>
Content-Type: image/jpeg<cr ln>
Content-Range: bytes=0-999/64911<cr ln>
<cr ln>
<binary JPEG data><cr ln>
--<boundary><cr ln>
...(2nd part)...<cr ln>
--<boundary><cr ln>
...(3rd part)...<cr ln>
--<boundary>--<cr ln>        (last boundary)

Upvotes: 1

Related Questions