postman发送object_.NetCore HttpClient发送请求的时候为什么自动带上了一个RequestId头部...

在调用第三方webservice时遇到504错误,通过Postman测试发现请求带有'postman-token'头导致失败。进一步使用Fiddler监控发现.NET Core HttpClient自动添加了'Request-Id'头,引发问题。源码分析揭示HttpClient的Diagnostics机制是罪魁祸首。解决方案包括禁用ActivityPropagation或自定义Handler。
摘要由CSDN通过智能技术生成

奇怪的问题

最近在公司有个系统需要调用第三方的一个webservice。本来调用一个下很简单的事情,使用HttpClient构造一个SOAP请求发送出去拿到XML解析就是了。 可奇怪的是我们的请求在运行一段时间后就会被服务器504给拒绝掉了。导致系统无法使用,用户叫苦连天。 古怪就古怪在这个问题不是每次都会出现,是隔三差五的查询,每次修改完代码发布上去以为好了, 过了两天又不行了,简直让人奔溃。

Postman测试

在反复调试代码无果的情况下,我怀疑是对方服务器的问题。于是拿出Postman往对方服务器发送请求测试。 postman测试一测就测出问题了,不管发送什么,服务器全部给出了504的响应。因为在浏览器里访问webservice的首页是可以的,但是为什么在postman上面就不行了呢? 于是我开始反复检查postman的请求有何不同,到这里感觉离发现问题不远了。在反复查看下我开始怀疑是postman的一个头部的问题:

  1. Postman-Token: 4d407574-636b-9343-8216-7f2845cbeef1

postman每次发送请求的时候都会带上一个叫做postman-token的头部。于是我把这个头部给禁用了再试一次,果断成功了。 在反复测试下终于明白了,对方服务器应该有防护,只要http请求里带有自定义的头部就会直接给出504的响应,直接拒绝请求。 至此服务器拒绝请求的原因终于明了了。

fiddler监控

但是,我们的代码发送请求的时候并没有带上任何自定义的头部啊。莫非.NET Core会在发送请求的时候带上什么头部吗? 于是在服务器上安装fiddler,把请求通过fiddler代理转发出去,然后监控http请求的头部。当系统再次出现问题的时候 果断上去查看fiddler。一看果然发现了问题,所有被拒绝的请求都带上了一个叫“Request-Id”的头部。

8e58132fcd8c96c752708bcc96a5f7c3.png

当时我是震惊的,.NetCore居然会自说自话给我加上一个头部? 如果不是亲身发现,打死我也不会相信的。或许你看到这里也还是不相信,心里在想一定是我搞错了吧。

Request-Id头部到底哪里来的?

这个问题真是百思不得其解,于是开始请教google。很快在.net core runtime的github上的issues发现一个同样的问题:
HttpClient automatically adds Request-Id HTTP header
提问的人说使用HttpClient发送请求的时候莫名其妙加上了一个Request-Id,跟我情况一毛一样。
于是乎有人开始讨论。有人说HttpClient不可能自己加上Request-Id这个头部的,下面的老哥直接打脸,说:事实上会的,还给出了源码的位置。笑哭!后来还有开发者回复这个功能是内置的,是为了分布式追踪。
既然源码都给出来了,直接从上面老哥给出的源码位置开始追源码。下面大概说一下源码:
HttpClient默认构造函数:

  1. public HttpClient()
  2. : this(new HttpClientHandler())
  3. {
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值