Why is my de-chunked request missing the ending CRLF?

Question

I've just spent the past 10 hours trying to figure out why my http request was failing when I did a

request.Content.ReadAsMultipartAsync().Result.Contents

It kept returning the error:

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

After many hours of research, I finally discovered that the request did not have an ending CRLF, which apparently .Net needs to determine the end of the request. When I added my own CRLF, everything worked great.

In WireShark, I looked at one of the requests, I saw that the chunked request did have an ending CRLF, but the De-Chunked request did not.

So that leaves me with 2 questions.

1. Why is my request missing the ending CRLF, and
2. Is there any way to add it back before it gets to .Net so that .Net will process it correctly? Or, can I tell .Net to not look for the ending CRLF?

Answer 1

The two CRLFs that you circled in the last chunk of the chunked mode are part of the chunked transfer encoding, which specifies a CRLF after the number of bytes in each chunk (zero in the last chunk of the request/response entity) and an additional CRLF after the whole thing (see RFC 2616, section 3.6.1). MIME multipart (RFC 2046, section 5.1.1) does not require a CRLF after the last boundary, so the service you're receiving the entity from is not wrong when it doesn't add it. OTOH, the old .NET multipart parser was buggy in rejecting it. The ASP.NET team fixed the issue late last year, so you just need to use an up-to-date System.Net.Http.Formatting (ASP.NET WebApi client libraries 5.1.0 should be OK). If you absolutely can't use the up-to-date assembly, then, to work around the problem, I'd wrap the underlying stream with a special wrapper stream that supplies the trailing CRLF.