简体   繁体   中英

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

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.

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)

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM