由Http Post提交遇到的一个坑，深入详解4种Post发送数据编码方式

由Http Post提交遇到的一个坑，深入详解4种Post发送数据编码方式

阅读引导：

1、Http post的4中提交方式详解

2、遇到的一个较深的坑，以及解决思路。

最近团队的某个项目遇到一个诡异的问题。

通过生产应用程序调用客户的服务时，报错500.

但是，通过Postman模拟报文发送相同，却返回正确。

难点在于客户的生产程序没有打日志……据了解，客户使用的是C#开发，开发人员已经交接过多次，无法确认程序问题。

不过幸好，这个客户提供的服务通信协议是Http。也就是说，可以通过网络抓包解决。

1

解决路径

由于是客户报错500，而对方又不配合排查，且程序没有打印日志，只能猜测那个地方可能出问题。（苦逼的乙方）

一个大背景是在去年，双方已经在测试环境经过了验证，然后投产了。

但是双方程序员都坚称自己没有改动过程序……

经过一系列的混乱后，制定了解决路径方法。

首先，业务协调客户开发人员加上日志，在晚上配合临时替换生产程序，查出到底是哪里报错。

其次，生产环境抓包，本地互联网环境也抓postman 的发送请求报文，比较异同点。（幸好对方是http）

2

问题原因

由于开发环境管控，开发人员进行postman发送，并安装wireshark抓包，进展缓慢。

幸而，客户方面取得突破。

上线日志打印之后，终于发现问题。

客户程序对于Http请求报文序列化之后，得到的参数有一些是空，但是我方发送报文明明是发送了参数。

然后，客户又在处理Http报文的入口，进来就打印程序，发现所有的参数全部都存在。

因此，怀疑是客户那边自己的程序出了问题。

但是，后来客户坚称没有改动，也不愿因此改动。

比对了一些Http请求报文后，发现入口程序打印的请求参数部分类似这样：&syscode&transcode=12345

客户开发人员称：对方是C#的处理框架，对于参数为空的方式，也必须送“=”，也就是说，上面部分的内容应该是：&syscode