Description
Description
RFC 1341 (MIME) 7.2 and all its successors state that multipart messages must contain one or more body parts. A multipart message with no body parts, i.e. consisting of only the closing multipart delimiter, violates the standard. Probably for this reason, System.Net.Http.MultipartContent with zero parts added to it writes itself as a dummy empty part with no content headers or message body. This output follows the letter of the RFC, but may not be what users of MultipartContent without deep knowledge of the RFC expect to happen. Multipart reader implementation in HttpContentMultipartExtension from System.Net.Http.Formatting has a special check to read the resulting message as a multipart content with zero parts (it discards the dummy empty part).
However, (a) other HTTP clients may not interpret this message in the same way, potentially leading to unexpected results, and (b) the RFC does not appear to single out empty parts with no headers or content as being in any way special (chapter 7.2 specifically states that in body parts all headers are optional), so this looks like a backward compatibility. As such, it is almost certainly going to stay that way, although it would probably be more correct for a MultipartContent with zero parts added to it to throw an exception when written out.
Reproduction Steps
Console.WriteLine (await new MultipartContent ("mixed", "111").ReadAsStringAsync ());
prints
--111
--111--
Expected behavior
I suggest adding a sentence to the description of MultipartContent to document this behavior.
Actual behavior
A MultipartContent with zero parts added writes itself as a single dummy empty body part.
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
No response