问题描述#
上图示例展示了用户通过 IOS 客户端发送请求时，对应后端接口接收到的 Request 内容。从请求内容的整体结果，我们可以看出这是一个 multipart/form-data 的数据格式，由于这种数据是由多个 multipart section 组成，所以我们可以看出在这个请求体中，是包含3个 section ，name 值分别为 Agree，CultureCode，FingerSignature，每个 section 都会包含一个 Content-Disposition 字段，前面两个 section都是普通的数据格式，最后一个是图片类型的数据。当后端接口接收到这样一个请求体时，尝试使用 Request.Form.Files 的方式来获取目标文件时，发现无法获取 FingerSignature 对应的文件内容。
问题分析#
通过和客户沟通，了解到FingerSignature 对应的文件是会被一起放到请求体中传给后端，客户表示前端APP这一块的逻辑在后端还没有升级成 ASP.NET Core（处于 Framework 阶段）的时候是可以正常工作的。通过查看ASP.NET Core 中对 Request.Form 的赋值逻辑： FormFeature 实现，找到了如下逻辑函数：
通过源码的逻辑，我们可以看出，只有当前的 section 对应的 Content-Disposition 同时包含 form-data 和 fileName (或 fileNameStar)，才会被作为文件来处理（示例：form-data; name="FingerSignature"; fileName="xxxx.jpeg"），否则并不会把当起的 Section 添加到 Request.Form.Files 中。此时结合上面获取的请求内容，定位到 FingerSignature 部分的 Content-Disposition 中由于缺少 fileName 字段导致后端无法解析到对应文件为该issue 的 Root Cause。
解决方案#
由于前端 APP 已经发布多个版本，所以让前端来补全这个字段显然不是一种稳妥的修复方案，因此后端需要做一个兼容性处理。当遇到这种不是标准格式的文件内容，需要通过 MultipartReader 对象来处理 MultipartFormDataContent 对应的 Section 内容（实际上 Request.Form.Files 底层逻辑就是通过 MultipartReader 来依次解析每个 Section 内容）。这里实现了一个方法来获取当前 MultipartFormDataContent 中的所有文件：
在这个方法中有2个细节地方需要注意。
- 默认情况下，Request.Body 中的内容只允许读取一次，所以我们需要在使用这个方法的路由地方启用 EnableBuffering 设置，这里可以自定义一个 Filter 来复用这种特性：
- 因为对 Request.Body开启 EnableBuffering 了，所以在调用 ReadFilesAsyns 方法的时候，不确定此时 Body 中的 Stream起始位置为 0。所以我们需要在读取 Body 之前和之后通过 Seek 方法将 Stream的 Position 重置归 0。
优化建议#
从目前的修复方案来讲的话，后端只是提供了一种妥协的修复方案来适配前端的数据不完整，因此感觉比较完善的修复方案是前端在发送 multipart/form-data 的数据时，尽量以标准的方式来构建每个 Section 内容，尤其是文件类型。如果前后端都能以统一的数据格式来进行交互，自然也就不会出现上述所说的这种问题，潜在的风险自然也就变小了。