使用Spring處理x-www-form-urlencoded方式
Spring處理x-www-form-urlencoded方式
最近在重寫一個(gè)項(xiàng)目時(shí)遇到了許多奇葩問題,這個(gè)項(xiàng)目是一個(gè)簡單的web后臺項(xiàng)目,基本上全都是增刪改查數(shù)據(jù)庫的操作。這里面遇到幾個(gè)用spring接收前端post請求的接口。
基本情況是post請求有四種data參數(shù)格式,這些基礎(chǔ)知識在我另一片博文中提到過這里就不廢話了。主要是因?yàn)榍岸擞袃蓚€(gè)地方用到了這個(gè)接口,但是在用這個(gè)接口的時(shí)候兩個(gè)地方用法都不同,奇葩的c++居然還都解析成功了(其實(shí)因?yàn)閏++沒有對請求參數(shù)格式和數(shù)據(jù)做檢查所以一直沒有問題)。
一個(gè)地方是發(fā)送的是application/json格式,發(fā)送了一個(gè)jsonArray數(shù)據(jù)(數(shù)據(jù)例子["abc", "bcd"])這個(gè)是沒有問題的正確使用方式。(下面簡稱前者)
另一個(gè)地方是發(fā)送的application/x-www-form-urlencode格式,發(fā)送的也是一個(gè)jsonArray數(shù)據(jù)。(下面簡稱后者)
前者解析方式比較簡單
@RequestMapping(value = "/check_apps_version",
method = RequestMethod.POST,
produces = {"application/json;charset=UTF-8"},
consumes = MediaType.APPLICATION_JSON_UTF8_VALUE)
@ResponseBody
public BaseResponse<List<AppListItem>> checkAppsVersion(ReqCheckAppsVersion requstParam,
@RequestBody List<String> apps) {
return new BaseResponse<>();
}
后者這個(gè)發(fā)送方式在spring用@RequestBody解析時(shí)就很怪異,但是前段是手機(jī)APP已經(jīng)發(fā)布出去了沒法修改,只能后端來修改滿足這個(gè)奇怪的需求
通過調(diào)試發(fā)現(xiàn)后者前端的接口傳過來的參數(shù)是"["abc","def"]="這樣子的,本身x-www-form-urlencode是多個(gè)kev-value對的數(shù)據(jù)格式,所以現(xiàn)在沒有value只有key了,只能通過字符串處理來解決了。
@RequestMapping(value = "/check_apps_version",
method = RequestMethod.POST,
produces = {"application/json;charset=UTF-8"},
consumes = MediaType.APPLICATION_FORM_URLENCODED_VALUE)
@ResponseBody
public BaseResponse<List<AppListItem>> checkAppsVersionParams(HttpServletRequest request,
ReqCheckAppsVersion requstParam,
@RequestBody String apps) {
String body = request.getReader().lines().collect(Collectors.joining(System.lineSeparator()));
return BaseResponse.success();
}
兩種方式,一種是通過@RequestBody把post data解析成string格式,另一種是通過HttpServletRequest解析出整個(gè)原始post data。然后做字符串處理。
但是在做做這個(gè)測試時(shí)候我們想了一下會不會有只有value沒有key的情況,也就是這樣"=["abc","def"]"。
測試結(jié)果是用tomcat沒法從HttpServletRequest到這個(gè)post data,但是用jetty可以從HttpServletRequest解析到post data。
這個(gè)可能是tomcat和jetty的區(qū)別吧,還沒有弄清楚什么原因。但是我們的問題總算是解決了,最大感觸就是前人挖坑后人埋啊。
希望以后能注意一下代碼健壯性的問題,避免給別人或者自己挖坑。
關(guān)于application/x-www-form-urlencoded編碼
同事遇到在servlet端通過request對象getInputStream讀取POST過來的數(shù)據(jù),卻讀不到的問題,懷疑是tomcat的問題。查了一下Content-type是application/x-www-form-urlencoded,估計(jì)是被解析成了parameters,果然在他獲取流之前,有過request.getParameter的操作。
熟悉servlet的話,這個(gè)問題應(yīng)該算常識了。它其實(shí)跟容器無關(guān),所有的servlet容器都是這樣的行為。幾年前在實(shí)現(xiàn)一個(gè)網(wǎng)關(guān)代理的時(shí)候就遇到過這個(gè)問題,當(dāng)時(shí)使用的是jetty,發(fā)現(xiàn)POST過來的數(shù)據(jù)讀不到,也是application/x-www-form-urlencoded編碼,斷點(diǎn)跟蹤發(fā)現(xiàn)是在獲取流之前有過request.getParameter,數(shù)據(jù)會被解析,并且后續(xù)數(shù)據(jù)流不可再被讀取。
在servlet規(guī)范3.1.1節(jié)里,對POST數(shù)據(jù)何時(shí)會被當(dāng)做parameters有描述:
1. The request is an HTTP or HTTPS request.
2. The HTTP method is POST.
3. The content type is application/x-www-form-urlencoded.
4. The servlet has made an initial call of any of the getParameter family of methods on the request object.
If the conditions are met, post form data will no longer be available for reading directly from the request object's input stream.
規(guī)范里已經(jīng)明確的聲明當(dāng)請求滿足:
1) http/https
2) POST
3) Content-type 是application/x-www-form-urlencoded
4) 調(diào)用過getParameter方法,則數(shù)據(jù)會被當(dāng)做請求的paramaters,而不能再通過 request 的 inputstream 直接讀取。
所以不論tomcat、jetty還是其他servlet容器都遵循這個(gè)方式。不過話說回來,為什么application/x-www-form-urlencoded編碼的數(shù)據(jù)會被當(dāng)做parameter來解析呢?
使用http上傳數(shù)據(jù)可以用GET或POST,使用GET的話,只能通過uri的queryString形式,這會遇到長度的問題,各個(gè)瀏覽器或server可能對長度支持的不同,所以到要提交的數(shù)據(jù)如果太長并不適合使用GET提交。
采用POST的話,既可以在uri中帶有queryString也可以將數(shù)據(jù)放在body中。body內(nèi)容可以有多種編碼形式,其中application/x-www-form-urlencoded編碼其實(shí)是基于uri的percent-encoding編碼的,所以采用application/x-www-form-urlencoded的POST數(shù)據(jù)和queryString只是形式不同,本質(zhì)都是傳遞參數(shù)。
在tomcat的Request.parseParameters方法里,對于application/x-www-form-urlencoded是有做判斷的,對這種編碼會去解析body里的數(shù)據(jù),填充到parameters里,所以后續(xù)想再通過流的方式讀取body是讀不到的(除非你沒有觸發(fā)過getParameter相關(guān)的方法)。
在HTML4之前,表單數(shù)據(jù)的編碼方式只有application/x-www-form-urlencoded這一種(現(xiàn)在默認(rèn)也是這種方式),因?yàn)樵缙诘臅r(shí)候,web上提交過來的數(shù)據(jù)也是非常簡單的,基本上以key-value形式為主,所以表單采用application/x-www-form-urlencoded這種編碼形式也沒什么問題。
在HTML4里又引入了multipart/form-data編碼,對于這兩種編碼如何選擇,請參考這里。
以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。
相關(guān)文章
Spring Security實(shí)現(xiàn)多次登錄失敗后賬戶鎖定功能
當(dāng)用戶多次登錄失敗的時(shí)候,我們應(yīng)該將賬戶鎖定,等待一定的時(shí)間之后才能再次進(jìn)行登錄操作。今天小編給大家分享Spring Security實(shí)現(xiàn)多次登錄失敗后賬戶鎖定功能,感興趣的朋友一起看看吧2019-11-11
Invalid?bound?statement?(not?found)出現(xiàn)原因以及解決辦法
這篇文章主要給大家介紹了關(guān)于Invalid?bound?statement?(not?found)出現(xiàn)原因以及解決辦法的相關(guān)資料,文中給出了詳細(xì)的解決方法,需要的朋友可以參考下2023-07-07
使用java基礎(chǔ)類實(shí)現(xiàn)zip壓縮和zip解壓工具類分享
使用java基礎(chǔ)類寫的一個(gè)簡單的zip壓縮解壓工具類,實(shí)現(xiàn)了指定目錄壓縮到和該目錄同名的zip文件和將zip文件解壓到指定的目錄的功能2014-03-03
解析Java的Spring框架的BeanPostProcessor發(fā)布處理器
這篇文章主要介紹了Java的Spring框架的BeanPostProcessor發(fā)布處理器,Spring是Java的SSH三大web開發(fā)框架之一,需要的朋友可以參考下2015-12-12
Java詳細(xì)分析String類與StringBuffer和StringBuilder的使用方法
當(dāng)對字符串進(jìn)行修改的時(shí)候,需要使用 StringBuffer 和 StringBuilder類,和String類不同的是,StringBuffer和 StringBuilder類的對象能夠被多次的修改,并且不產(chǎn)生新的未使用對象2022-04-04
關(guān)于Idea使用git時(shí)commit特別慢的問題及解決方法
這篇文章主要介紹了關(guān)于Idea使用git時(shí)commit特別慢的問題及解決方法,本文通過圖文并茂的形式給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2020-10-10
win10 java(jdk安裝)環(huán)境變量配置和相關(guān)問題
這篇文章主要介紹了win10java(jdk安裝)環(huán)境變量配置和相關(guān)問題解決,非常不錯(cuò),具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2019-12-12

