API unable to read multipart: Unexpected end of MIME multipart stream. MIME multipart message is not complete

Question

We have started encountering an issue since this weekend just gone. We send a file from an application on one server to an API on another.

Usually this API sits behind cloudflare's CDN/proxy, however since February 13th at around 01:00-02:00 this functionality only works without cloudflare proxying/CDN enabled (we've actually left it enabled but instead edited the host file of the sender to point to our real IP address, not cloudflare's). If we remove the sender application and use postman, the result is the same (using cdn fails, going direct works).

I have a ticket raised with their support, but I also wanted to sanity check this is not potentially something we have done incorrectly.

    [HttpPost]
    [Route("sendvideofile")]
    public async Task<CameraResponse> ReceiveVideoFile()
    {
        var content = await GetMultipartContent(this.Request.Content).EscapeContext();
        
        var stream = await content.ReadAsStreamAsync().EscapeContext();

        return CameraResponse.Create(true);
    }

This is our GetMultiPartContent method:

    private static async Task<HttpContent> GetMultipartContent(HttpContent requestContent)
    {
        var filesReadToProvider = await requestContent.ReadAsMultipartAsync().EscapeContext();

        return filesReadToProvider.Contents.FirstOrDefault();
    }

The exception thrown is:

Message:An error has occurred.
ExceptionMessage:Unexpected end of MIME multipart stream. MIME multipart message is not complete.
ExceptionType:System.IO.IOException
StackTrace: at System.Net.Http.Formatting.Parsers.MimeMultipartBodyPartParser.<ParseBuffer>d__0.MoveNext()
 at System.Net.Http.HttpContentMultipartExtensions.<MultipartReadAsync>d__8.MoveNext()
 --- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at System.Net.Http.HttpContentMultipartExtensions......

As you can see our code is quite simple in reality (I've cut some other proprietary service calls out which won't be causing this), but I am struggling to believe that Cloudflare could have rolled something out that caused base methods in dotnet framework to fail being able to read multipart streams. Or at least if they had, we would have heard about it or been told via our ticket.

If postman is failing the request is not formatted properly. Mime attachments start with a new line containing two dashes. See following example : https://learn.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2010/aa563375(v=exchg.140)?force_isolation=true — jdweng, Feb 18 '22 at 13:54
@jdweng but surely then, if that were the case, it would fail in all situations, not only when cloudflare's CDN was turned on, would you not think? — Seb, Feb 18 '22 at 13:55
I can't tell. All I know it that it failed after Feb 13th. And the current file is not working. — jdweng, Feb 18 '22 at 14:03

score 0 · Answer 1 · answered Jul 12 '22 at 12:33

I had a similar issue with an API, and the problem was related to the boundary not being closed.

Based on this SO question what-rules-apply-to-mime-boundary, the boundary must be ended of with a final --

I had an initial request body in POSTman (text/raw) with the following settings

Header

multipart/form-data;boundary=bee21932-0a3e-45a3-957d-e0b5f3e8f12e

Body

--bee21932-0a3e-45a3-957d-e0b5f3e8f12e 
Content-Type: multipart/form-data;boundary="9e73357f-6a62-452b-a1b8-2b48586435e5"
Content-Disposition: form-data
 
--9e73357f-6a62-452b-a1b8-2b48586435e5
Content-Type: application/x-www-form-urlencoded
Content-Disposition: form-data
 
DocumentId=3
--9e73357f-6a62-452b-a1b8-2b48586435e5--
 
--bee21932-0a3e-45a3-957d-e0b5f3e8f12e--

The problem is that this kept failing with the message

Unexpected end of MIME multipart stream. MIME multipart message is not complete.

So after finding the mentioned SO article, I updated the body to have an additional boundary:

--bee21932-0a3e-45a3-957d-e0b5f3e8f12e 
Content-Type: multipart/form-data;boundary="9e73357f-6a62-452b-a1b8-2b48586435e5"
Content-Disposition: form-data
 
--9e73357f-6a62-452b-a1b8-2b48586435e5
Content-Type: application/x-www-form-urlencoded
Content-Disposition: form-data
 
DocumentId=3
--9e73357f-6a62-452b-a1b8-2b48586435e5

--9e73357f-6a62-452b-a1b8-2b48586435e5-- //this was added

--bee21932-0a3e-45a3-957d-e0b5f3e8f12e--

And I got success. (I'm still not sure why the server requires this, but in case someone else needs this)

API unable to read multipart: Unexpected end of MIME multipart stream. MIME multipart message is not complete

1 Answers1