java向服务器写入文件失败_关于iOS移动端向Java服务器提交文件数据的一个坑

之前在做一个图片上传的功能时,由于是和新的同事进行对接,我居然没有开始就用封装好的方法!现在想想如果不是这样,也不能对HTTP的认识更加深刻了。而且还小小的了解了一下Java服务器的后台知识。

最原先我是将参数以及文件内容放在了HTTPBody里。

然后发出的报文其实就跟这个文章里面介绍的一样了:iOS POST 至 Java后台

但是失败了。。。而且返回的错误是服务器的错误码,好像是415吧~ 这样的话,说明同事的那个方法都没有进去。那么,有可能就是参数的问题。

后来让同事分别多写了两个方法,一个是只传参数,一个是只传文件的方法。测试之后发现只传参数的那个方法是可以调通的。

仔细分析两者的报文,再加上对比之前Web端的请求报文。发现问题应该是出现在了HTTP表单中的Content-Type这个字段里。

先附上一个前些日子收藏的关于HTTP协议的一篇帖子:HTTP协议详解

一般我们使用iOS请求网络的原生方法,或者使用AFNetworking时,如果没有特殊写明Content-Type这个字段的值,那么默认的应该就是:application/x-www-form-urlencoded这个值。比如下图

e0b6fe831aad

request_header.png

这种情况下的GET请求呢,会把所有参数转换为一个字符串,然后拼接在请求的地址后面,用?分割。如果是POST请求,会将数据封装到HTTPBody里面。

如果在请求里面有文件的话,那么你的Content-Type的值就不能是默认的值了,而应该是:multipart/form-data。比如下图

e0b6fe831aad

图片.png

而报文呢,也是有所不同,比如下图:

e0b6fe831aad

图片.png

图中上面的红框是普通的参数封装的样子,下面的红框是文件类型的参数封装的样子,下面那些乱码就是文件的Data流了。

那么,果断按照这种格式向服务器发起请求!

结果,出错了。

为什么呢?

和同事沟通过后发现,在这个接口的方法上方,有一个很显眼的关键字。

@RequestBody

以及@RequestMapping(value = "*********",consumes = 'application/json')

比如下图:

e0b6fe831aad

java_method.png

后台使用的是SpringMVC 的架构。

这样的设置,意味着接收的数据是json格式的字符串。然后将这个字符串封装到指定的对象里。也就是图中的

NativeReplayPo replay这个对象里。

将其删掉,重新请求,轻轻松松的就成功了。

经过这次风波之后,真是感慨,这个世界上如果有比女人更难懂的,那应该就是HTTP了。

也是自己基础的知识不够完善。写下此文,以示警戒。

e0b6fe831aad

情人总是分分合合,而我们却是越爱越深...

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值