問題發(fā)生

這周正在寫代碼，突然，旁邊小哥問我個問題...

• 小哥：我這有個接口，自己調(diào)用沒有問題，但別人調(diào)用就不行，這種問題該如何排查？
• 我：抓下包看看呢...
• 小哥：是這樣使用tcpdump嗎？
• 我：是的

待小哥抓到包后，使用wireshark打開，并找到了相應(yīng)的請求，類似如下：

然后我讓小哥將這個請求，使用curl發(fā)一個同樣的請求，看能不能復(fù)現(xiàn)這個錯誤，如下：

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

命令執(zhí)行之后，重現(xiàn)了調(diào)用方一樣的接口報(bào)錯。

然后抓包小哥自己的正確請求是這樣的：

先不管為什么缺這個會報(bào)錯，這里展示了一個實(shí)用技巧，對于http接口來說，排查這種接口調(diào)用差異問題，最直接高效的方法，就是對比正確調(diào)用與錯誤調(diào)用的數(shù)據(jù)包！

問題解決

那么接下來，就是研究為什么報(bào)錯了，看看服務(wù)端的處理代碼，大概如下：

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參數(shù)中取數(shù)據(jù)。
2. 若沒有再從請求體中拿。
3. 然后base64解碼。
4. 最后轉(zhuǎn)json對象。

我們接口基本都這樣，使用base64將數(shù)據(jù)包了一層，許多年過去了，具體原因不詳，不深究??

從上面處理邏輯看，按道理小哥的調(diào)用方式與別人的調(diào)用方式都是支持的，理論上來說，小哥的調(diào)用方式會命中request.getParameter，而別人的調(diào)用方式會命中request.getInputStream()，那為啥別人的調(diào)用方式不行？

小哥又調(diào)試了下上述服務(wù)端代碼，發(fā)現(xiàn)使用別人的調(diào)用方式時，從request.getInputStream()中讀不到數(shù)據(jù)??

我在小哥旁邊，提示將ContentType改成text/plain試試，curl命令改成這樣：

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

執(zhí)行這條命令后，接口返回了正確結(jié)果??

那為什么會這樣呢??????

ContentType指的是什么？

首先來看看ContentType指的是什么，看2個例子

1. 如果ContentType是application/x-www-form-urlencoded時，請求可能是這樣的：
   
2. 如果ContentType是application/json時，請求可能是這樣的：
   
3. 如果ContentType是application/xml時，請求可能是這樣的：
   
   
   不難發(fā)現(xiàn)，ContentType這個請求頭的作用是，指定請求體的數(shù)據(jù)格式。比如application/x-www-form-urlencoded表示請求體是key=value格式，application/json表示請求體是json格式，application/xml表示是xml格式，而text/plain表示請求體是純文本。

那為什么將ContentType從application/x-www-form-urlencoded變成text/plain，報(bào)錯的調(diào)用就能跑通了？

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

application/x-www-form-urlencoded是個歷史非常悠久的ContentType了，它通過key=value的形式來組織表單數(shù)據(jù)，當(dāng)然key和value還需要做urlencode編碼。

而正是因?yàn)樗绱擞凭茫员徊杉{在了web服務(wù)器的實(shí)現(xiàn)標(biāo)準(zhǔn)中，幾乎所有的web服務(wù)器，當(dāng)發(fā)現(xiàn)ContentType是application/x-www-form-urlencoded時，會自動按key=value&key2=value2的格式來解析請求體數(shù)據(jù)，解析完成后，我們就可以通過request.getParameter()來獲取對應(yīng)key的值了。

比如Tomcat的實(shí)現(xiàn)在org.apache.catalina.connector.Request#parseParameters，如下：

但是，這里有一個重要的細(xì)節(jié)！

當(dāng)ContentType是application/x-www-form-urlencoded時，由于Tomcat提前將請求體的數(shù)據(jù)流讀了一遍，所以后面再通過request.getInputStream()就讀不到請求體數(shù)據(jù)了。

如下，從request.getInputStream()中獲取到的流，pos游標(biāo)已經(jīng)走到了lim結(jié)束位置了。

而將ContentType改為text/plain后，Tomcat不會解析請求體，所以就不會讀數(shù)據(jù)流，自然后面我們通過request.getInputStream()就又能讀到數(shù)據(jù)了，故又可以調(diào)通了！

解決問題

解決這個問題很簡單，如下：

1. 讓調(diào)用方在請求體里加上data=，以符合application/x-www-form-urlencoded的key=value規(guī)范。
2. 讓調(diào)用方將ContentType修改為text/plain，因?yàn)檎{(diào)用方的請求數(shù)據(jù)就是base64純文本而已，我們讓調(diào)用方選擇了這個方案。

如果調(diào)用方有很多，難以確定調(diào)用方的規(guī)范情況，那其實(shí)還有一種方案，通過request.getParameterMap()實(shí)現(xiàn)，代碼有點(diǎn)hack(常規(guī)場景不推薦)，如下：