为什么我的de-chunked请求错过了结束CRLF？

Question

我在过去的10个小时里一直在努力弄清楚为什么我的http请求在我执行时失败了

request.Content.ReadAsMultipartAsync().Result.Contents

它不断返回错误：

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

经过数小时的研究，我终于发现请求没有结束CRLF，显然.Net需要确定请求的结束。当我添加自己的CRLF时，一切都很好。

在WireShark中，我查看了其中一个请求，我看到分块请求确实有一个结束CRLF，但De-Chunked请求没有。

所以这给我留下了两个问题。

1. 为什么我的请求缺少结束CRLF和
2. 有没有办法在它到达.Net之前将其添加回来以便.Net将正确处理它？或者，我可以告诉.Net不要寻找结束的CRLF吗？

Answer 1

在分块模式的最后一个块中圈出的两个CRLF是chunked传输编码的一部分，它在每个块中的字节数之后指定CRLF（请求的最后一个块中为零） / response entity）和整个事件之后的另一个CRLF（参见RFC 2616，第3.6.1节）。 MIME多部分（RFC 2046，第5.1.1节）在最后一个边界之后不需要CRLF，因此当您不添加实体时，您接收该实体的服务没有错误。 OTOH，旧的.NET多部分解析器buggy拒绝它。 ASP.NET团队fixed the issue去年年底，所以你只需要使用最新的System.Net.Http.Formatting（ASP.NET WebApi客户端库5.1.0应该没问题）。如果你绝对不能使用最新的程序集，那么，为了解决这个问题，我将使用一个特殊的包装流来包装底层流，该流提供尾随的CRLF。