网站建设行业地位,南昌百度搜索排名优化,WordPress制作小说网站,微信网页手机登录入口前言今天#xff0c;在对接一个第三方平台开放接口时遇到一个很棘手的问题#xff0c;根据接口文档组装好报文#xff0c;使用HttpClient发起POST请求时一直超时#xff0c;对方服务器一直不给任何响应。发起请求的代码如下#xff1a;using (var httpClient new HttpCli… 前言今天在对接一个第三方平台开放接口时遇到一个很棘手的问题根据接口文档组装好报文使用HttpClient发起POST请求时一直超时对方服务器一直不给任何响应。发起请求的代码如下using (var httpClient new HttpClient())
{var msg new HttpRequestMessage(){Content new StringContent(postJson, Encoding.UTF8, application/json),Method HttpMethod.Post,RequestUri new Uri(apiUrl),};// 这里会一直阻塞直到超时var res httpClient.SendAsync(msg).ConfigureAwait(false).GetAwaiter().GetResult();if (res.StatusCode ! HttpStatusCode.OK){throw new Exception(res.StatusCode.ToString());}return res.Content.ReadAsStringAsync().ConfigureAwait(false).GetAwaiter().GetResult();
}异步请求超时取消错误如下这种情况首先怀疑对方服务是不是有问题 然而经过确认对方服务没问题并且使用将请求的url和报文粘贴到PostMan进行请求迅速得到返回报文一切正常。排除了对方服务的问题那是我们的代码问题可是上面HttpClient发起Post请求的代码写了不知道多少遍一直都没问题今天怎么就不行了呢我敢保证这么写没毛病。遇到这种情况该如何解决呢爬坑过程遇到这种问题相比大部分人开始各种参数换来换去各种库换来换去可能最终蒙成了。但是这里我相信PostMan可以请求成功强大的HttpClient一定可以一定是是哪个参数问题有经验的老手首先就会想到: 接口的协议中是不是对Header有什么特别的要求这里查询文档没有什么特别要求。控制变量法既然我们不知道为什么也猜不到那就控制变量法去解决。这里能想到的就是抓包抓取PostMan成功的请求报文以及我们失败的报文对比差异。抓包工具使用的是FiddlerPostman报文POST http://xxx.xxx.xxx.xxx:30000/parking/carin/V1 HTTP/1.1
Content-Type: application/json
User-Agent: PostmanRuntime/7.29.2
Accept: */*
Postman-Token: 14547b64-d8f6-4b0b-9fa9-48c9ec74a8f6
Host: xxx.xxx.xxx.xxx:30000
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 563{data: ...这里省略了具体json内容}HttpClient报文POST http://118.31.110.35:30000/parking/carin/V1 HTTP/1.1
Content-Type: application/json; charsetutf-8
Host: 118.31.110.35:30000
Content-Length: 563
Expect: 100-continue
Connection: Keep-Alive{data: ...这里省略了具体json内容}差异排查因为body中的内容是一样的这里就不用对比了。两个请求的Header存在差异那我们就将差异一个一个抹平。Content-Type在HttpClient中多了charsetutf-8这个应该不影响http协议默认就是utf8。User-Agent在HttpClient中没有那我们加上一模一样的User-Agent测试依旧超时。Accept在HttpClient中没有抹平测试依旧超时。Postman-Token在HttpClient中没有抹平测试依旧超时。Accept-Encoding在HttpClient中没有抹平测试依旧超时。到这里Postman中有的我们HttpClient中都有了竟然还超时这里虽然已经保证大部分参数都一样了但是控制变量法要求所有参数都一样这里还没有保证因为HttpClient多了一个Expect头我们还没保证一致。HttpClient的请求头中Expect: 100-continue在Postman报文中不存在去掉Expect测试成功了那我们锁定Expect: 100-continue导致了我们的请求无响应还原之前所有的抹平操作仅仅移除Expect: 100-continue测试依然成功。本文为Gui.H原创文章发布于公众号dotnet之美博客园首发https://www.cnblogs.com/springhgui/p/16499439.html最终解决前言中的问题仅仅需要添加一行代码msg.Headers.ExpectContinue false;ExpectContinues属性文档至此问题解决控制变量yydsExpect是什么参考Expect的定义 https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ExpectExpect 是一个请求消息头包含一个期望条件表示服务器只有在满足此期望条件的情况下才能妥善地处理请求。Expect规范中只规定了一个期望条件即 Expect: 100-continue, 对此服务器可以做出如下回应100 如果消息头中的期望条件可以得到满足使得请求可以顺利进行的话417 (Expectation Failed) 如果服务器不能满足期望条件的话也可以是其他任意表示客户端错误的状态码4xx。例如如果请求中 Content-Length 的值太大的话可能会遭到服务器的拒绝。Expect有啥好处让客户端在发送请求数据之前去判断服务器是否愿意接收该数据如果服务器愿意接收客户端才会真正发送数据如果客户端直接发送请求数据但是服务器又将该请求拒绝的话这种行为将带来很大的资源开销。Expect有啥坑不是所有的服务器都会正确应答100-continue, 比如lighttpd, 就会返回417 Expectation Failed。超时的原因HttpClient默认携带了Expect头我们请求带上了Expect: 100-continue的话是不会立刻发送body中的报文给服务器需要服务器需要对Expect: 100-continue做出响应然而对方服务器不支持Expect当然不能做出响应在前言说的问题中也就是HttpClient在等对方服务器响应Expect然后再发送报文而对方服务器看来我们怎么还不发送报文过来双方都在等数据最终HttpClient超时~以上纯属个人理解有不正确之处还请指正~
