由x-www-form-urlencoded引发的接口对接失败

原创：扣钉日记（微信大众号ID：codelogs），欢迎分享，非大众号转载保留此声明。

问题发生

这周正在写代码，突然，旁边小哥问我个问题…

• 小哥：我这有个接口，自己调用没有问题，但他人调用就不可，这种问题该如何排查？
• 我：抓下包看看呢…
• 小哥：是这样运用tcpdump吗？
• 我：是的

待小哥抓到包后，运用wireshark翻开，并找到了相应的恳求，相似如下：

然后我让小哥将这个恳求，运用curl发一个同样的恳求，看能不能复现这个错误，如下：

$ curl -X POST localhost:80/api \
      -H 'Content-Type: application/x-www-form-urlencoded' \
      -d 'eyJvcmRlcl9pZCI6MTIzNDU2Nzg5MDIxNDN9Cg=='

指令履行之后，重现了调用方一样的接口报错。

然后抓包小哥自己的正确恳求是这样的：

这里很简单发现，他人调不通接口，小哥能调通，原因是他人的恳求体里面缺失data=这一段

先不论为什么缺这个会报错，这里展示了一个实用技巧，对于http接口来说，排查这种接口调用差异问题，最直接高效的方法，就是比照正确调用与错误调用的数据包！

问题处理

那么接下来，就是研究为什么报错了，看看服务端的处理代码，大概如下：

public JsonObject parseRequest(HttpServletRequest request, Charset charset) throws IOException {
      String base64Str = request.getParameter("data");
      if (base64Str == null) {
            try (InputStream is = request.getInputStream()) {
                  base64Str = StreamUtils.copyToString(is, charset);
            }
      }
      byte[] jsonBytes = Base64.getDecoder().decode(base64Str);
      return new Gson().toJsonTree(new String(jsonBytes, charset)).getAsJsonObject();
}

这个逻辑很简单，如下：

1. 先从data参数中取数据。
2. 若没有再从恳求体中拿。
3. 然后base64解码。
4. 最后转json对象。

咱们接口根本都这样，运用base64将数据包了一层，许多年过去了，详细原因不详，不深究

从上面处理逻辑看，按道理小哥的调用方法与他人的调用方法都是支持的，理论上来说，小哥的调用方法会射中request.getParameter，而他人的调用方法会射中request.getInputStream()，那为啥他人的调用方法不可？

小哥又调试了下上述服务端代码，发现运用他人的调用方法时，从request.getInputStream()中读不到数据

我在小哥旁边，提示将ContentType改成text/plain试试，curl指令改成这样：

$ curl -X POST localhost:80/api \
      -H 'Content-Type: text/plain' \
      -d 'eyJvcmRlcl9pZCI6MTIzNDU2Nzg5MDIxNDN9Cg=='

履行这条指令后，接口返回了正确成果

那为什么会这样呢

ContentType指的是什么？

首先来看看ContentType指的是什么，看2个例子

1. 假如ContentType是application/x-www-form-urlencoded时，恳求可能是这样的：
   

   

2. 假如ContentType是application/json时，恳求可能是这样的：

   

3. 假如ContentType是application/xml时，恳求可能是这样的：
   

   

不难发现，ContentType这个恳求头的作用是，指定恳求体的数据格局。比方application/x-www-form-urlencoded表明恳求体是key=value格局，application/json表明恳求体是json格局，application/xml表明是xml格局，而text/plain表明恳求体是纯文本。

那为什么将ContentType从application/x-www-form-urlencoded变成text/plain，报错的调用就能跑通了？

application/x-www-form-urlencoded有何不同？

application/x-www-form-urlencoded是个前史非常悠久的ContentType了，它经过key=value的方式来组织表单数据，当然key和value还需要做urlencode编码。

而正是由于它如此悠久，所以被采用在了web服务器的完成标准中，几乎一切的web服务器，当发现ContentType是application/x-www-form-urlencoded时，会主动按key=value&key2=value2的格局来解析恳求体数据，解析完成后，咱们就能够经过request.getParameter()来获取对应key的值了。

比方Tomcat的完成在org.apache.catalina.connector.Request#parseParameters，如下：

解析key=value格局数据如下：

可是，这里有一个重要的细节！

当ContentType是application/x-www-form-urlencoded时，由于Tomcat提早将恳求体的数据流读了一遍，所以后边再经过request.getInputStream()就读不到恳求体数据了。

如下，从request.getInputStream()中获取到的流，pos游标已经走到了lim完毕位置了。

而将ContentType改为text/plain后，Tomcat不会解析恳求体，所以就不会读数据流，天然后边咱们经过request.getInputStream()就又能读到数据了，故又能够调通了！

处理问题

处理这个问题很简单，如下：

1. 让调用方在恳求体里加上data=，以契合application/x-www-form-urlencoded的key=value标准。
2. 让调用方将ContentType修改为text/plain，由于调用方的恳求数据就是base64纯文本而已，咱们让调用方选择了这个计划。

假如调用方有许多，难以确定调用方的标准情况，那其实还有一种计划，经过request.getParameterMap()完成，代码有点hack(惯例场景不推荐)，如下：

这是由于，在application/x-www-form-urlencoded中，key=value格局，value为空时，能够传key=，也能够省掉掉等号传key，所以咱们取第一个key值就拿到了恳求体数据。