上传文件 about umi-request

[tangyefei]

推荐的用法

个人理解图片上传的官方推荐应该是组合 requestType 和 data：

  requestType: 'form'
  data: formData,

请求头的content-type应该为 multipart/form-data, 如果是 application/x-www-form-urlencoded 说明自己写法不对，@Clago 的用法即可解决。尝试自己指定 multipart/form-data 会因为没有 boundary 而报错。

兼容性问题

另外一种情况是采用了标准用法也会识别为错误的content-type。问题原因是：在iOS下的某些浏览器内核（比如钉钉），会将FormData对象识别为Object，从而导致content-type也会被识别为 application/x-www-form-urlencoded 。

下面是源码的截图，不难理解：

• data应该被是识别为 FormData，从而进入 绿色 case的逻辑；
• data 被识别为了 Object，结合 requestType :'form' 的设定，进入了 红色 case的逻辑，从而导致了兼容性问题，无法上传

解决办法

requestType + data 最后会被转化成 body 和 content-type，content-type的判定逻辑会有漏洞，如果前端只传递 body 即可绕过这个有问题的检测，将content-type的判定交给浏览去做。

export async function fileUpload(file: File) {
  const formData = new FormData();
  formData.append('file', file, file.name);
  return request<API.Result<SYSTEM.FileType>>(`/app/images/upload`, {
    method: 'POST',
    body: formData,
  });
}

axios的做法

umi-request 和 axios 识别 FormData 的方法都是都是Object.toString 来判定字符串。

如果识别为 FormData 类型，就删除用户传递的 content-type，交给浏览器自己识别；不能识别FormData，如果也传递了content-type的话，也会有兼容性问题，最好就是不代码传 content-type。

[Clago]

没有 我修正了请求头 也有这个问题

这个是上传文件样例，request.post(/api/res/file,{requestType: 'form',data:parameter})。
原因就是全局里别指定header，单独的api也不要指定header。data为formData类型的话，就会自动加上boundary了。

[summer789]

我也有这个问题，没有设置请求头，也不对。

[Clago]

解决了吗，看文档说formdata会自动转换，根本就没有，坑啊。@wentools

[Clago]

原因找到了，request.js里extend别指定全局头信息，我指定了application/x-www-form-urlencoded。

[wentoos]

request('/api/file/fileController/fileUpload', {
method: 'POST',
data: formData,
headers: {
// Authorization: localStorage.getItem('token')!,
// 'Content-Type': 'multipart/form-data;',’application/x-www-form-urlencoded; charset=utf-8‘
},
});

[wentoos]

没有 我修正了请求头 也有这个问题

[Clago]

没有 我修正了请求头 也有这个问题

不要在reques.js里全局设置header，自己写的api里表单提交用加上参数requestType:'form'.

request(`/api/xxx`, {
    method: 'post',
    requestType: 'form',
    data: params,
  })

之前不知道这个参数，设置了全局头application/x-www-form-urlencoded，再用qs转，走了弯路。

[ystarlongzi]

原因就是全局里别指定header，单独的api也不要指定header。data为formData类型的话，就会自动加上boundary了。

这个解释是对的。但是和 requestType: 'form', 是无关的

[81777268]

我也有这个问题，没有设置请求头，也不对。

[zhangjinhao-work]

妈啊，真是找好久，终于解决了

[Yrobot]

太难了，就是全局设置headers的问题，我看到这个issure后注释了全局header就好了。太坑了，debug了一下午

[wj100]

'Content-Type': false也不起作用，就是覆盖不了，后端一直500还扯皮、、、重新new一个不加content-type的请求实例就好了
希望有缘人能看到 解决办法：https://blog.csdn.net/qq_44472722/article/details/117417101

[wood3n]

指定requestType: "form" 就行，不用再指定请求头"Content-Type: multipart/form-data"，否则后端就是会一直500；文档 https://github.com/umijs/umi-request/blob/master/README_zh-CN.md#%E6%96%87%E4%BB%B6%E4%B8%8A%E4%BC%A0 需要补充一下

[jiangkaifree]

对需要指定 requestType: "form"即可 ，如果全局指定了 content-type 也需要去掉，会自动添加对应的

[Mathround]

太难了，就是全局设置headers的问题，我看到这个issure后注释了全局header就好了。太坑了，debug了一下午

我直接把header删掉了也不行，最后请求自动带上的请求头不是aplication/json就是其他请求头，偏偏不是multipart/form-data

[lidongze0629]

推荐的用法

个人理解图片上传的官方推荐应该是组合 requestType 和 data：

  requestType: 'form'
  data: formData,

请求头的content-type应该为 multipart/form-data, 如果是 application/x-www-form-urlencoded 说明自己写法不对，@Clago 的用法即可解决。尝试自己指定 multipart/form-data 会因为没有 boundary 而报错。

兼容性问题

另外一种情况是采用了标准用法也会识别为错误的content-type。问题原因是：在iOS下的某些浏览器内核（比如钉钉），会将FormData对象识别为Object，从而导致content-type也会被识别为 application/x-www-form-urlencoded 。

下面是源码的截图，不难理解：

• data应该被是识别为 FormData，从而进入 绿色 case的逻辑；
• data 被识别为了 Object，结合 requestType :'form' 的设定，进入了 红色 case的逻辑，从而导致了兼容性问题，无法上传

解决办法

requestType + data 最后会被转化成 body 和 content-type，content-type的判定逻辑会有漏洞，如果前端只传递 body 即可绕过这个有问题的检测，将content-type的判定交给浏览去做。

export async function fileUpload(file: File) {
  const formData = new FormData();
  formData.append('file', file, file.name);
  return request<API.Result<SYSTEM.FileType>>(`/app/images/upload`, {
    method: 'POST',
    body: formData,
  });
}

axios的做法

umi-request 和 axios 识别 FormData 的方法都是都是Object.toString 来判定字符串。

如果识别为 FormData 类型，就删除用户传递的 content-type，交给浏览器自己识别；不能识别FormData，如果也传递了content-type的话，也会有兼容性问题，最好就是不代码传 content-type。

兼容性问题也请仔细读读，body的这个解决了我的问题

[jiangkaifree]

感谢 

…

------------------&nbsp;原始邮件&nbsp;------------------ 发件人: "umijs/umi-request" ***@***.***&gt;; 发送时间:&nbsp;2022年4月14日(星期四) 晚上8:22 ***@***.***&gt;; ***@***.******@***.***&gt;; 主题:&nbsp;Re: [umijs/umi-request] 上传文件 (#98) 推荐的用法 个人理解图片上传的官方推荐应该是组合 requestType 和 data： requestType: 'form' data: formData, 请求头的content-type应该为 multipart/form-data, 如果是 application/x-www-form-urlencoded ***@***.*** 的用法即可解决。尝试自己指定 multipart/form-data 会因为没有 boundary 而报错。 兼容性问题 另外一种情况是采用了标准用法也会识别为错误的content-type。问题原因是：在iOS下的某些浏览器内核（比如钉钉），会将FormData对象识别为Object，从而导致content-type也会被识别为 application/x-www-form-urlencoded 。 下面是源码的截图，不难理解： data应该被是识别为 FormData，从而进入 绿色 case的逻辑； data 被识别为了 Object，结合 requestType :'form' 的设定，进入了 红色 case的逻辑，从而导致了兼容性问题，无法上传 解决办法 requestType + data 最后会被转化成 body 和 content-type，content-type的判定逻辑会有漏洞，如果前端只传递 body 即可绕过这个有问题的检测，将content-type的判定交给浏览去做。 export async function fileUpload(file: File) { const formData = new FormData(); formData.append('file', file, file.name); return request<API.Result<SYSTEM.FileType&gt;&gt;(`/app/images/upload`, { method: 'POST', body: formData, }); } axios的做法 umi-request 和 axios 识别 FormData 的方法都是都是Object.toString 来判定字符串。 如果识别为 FormData 类型，就删除用户传递的 content-type，交给浏览器自己识别；不能识别FormData，如果也传递了content-type的话，也会有兼容性问题，最好就是不代码传 content-type。 兼容性问题也请仔细读读，body的这个解决了我的问题 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***&gt;

[guohuihot]

这种全局设置覆盖不了，写死了吗