创意包装设计网站,深圳市住房和建设局办事大厅,如何查看一个网站的浏览量,有了域名就可以做网站了吗问题描述# 上图示例展示了用户通过 IOS 客户端发送请求时#xff0c;对应后端接口接收到的 Request 内容。从请求内容的整体结果#xff0c;我们可以看出这是一个 multipart/form-data 的数据格式#xff0c;由于这种数据是由多个 multipart section 组成#xff0c;所以我…
问题描述# 上图示例展示了用户通过 IOS 客户端发送请求时对应后端接口接收到的 Request 内容。从请求内容的整体结果我们可以看出这是一个 multipart/form-data 的数据格式由于这种数据是由多个 multipart section 组成所以我们可以看出在这个请求体中是包含3个 section name 值分别为 AgreeCultureCodeFingerSignature每个 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; nameFingerSignature; 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 内容尤其是文件类型。如果前后端都能以统一的数据格式来进行交互自然也就不会出现上述所说的这种问题潜在的风险自然也就变小了。
