Shulou(Shulou.com)06/02 Report--

This article is about how to use Spring to deal with x-www-form-urlencoded. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

The way Spring handles x-www-form-urlencoded

Recently, I encountered a lot of strange problems when rewriting a project, which is a simple web background project, which is basically all about adding, deleting, changing and checking the database. There are several interfaces that use spring to receive front-end post requests.

The basic situation is that there are four data parameter formats for post requests, which is not nonsense as mentioned in my other blog post. This is mainly because this API is used in two places at the front end, but the usage of this API in both places is different, and the strange C++ has been parsed successfully (in fact, there has been no problem because C++ has not checked the request parameter format and data).

One place is to send application/json format, send a jsonArray data (data example ["abc", "bcd"]) this is no problem with the correct use. (hereinafter referred to as the former)

Another place is to send the application/x-www-form-urlencode format, which is also a jsonArray data. (hereinafter referred to as the latter)

The former is relatively simple in parsing.

@ RequestMapping (value = "/ check_apps_version", method = RequestMethod.POST, produces = {"application/json;charset=UTF-8"}, consumes = MediaType.APPLICATION_JSON_UTF8_VALUE) @ ResponseBody public BaseResponse checkAppsVersion (ReqCheckAppsVersion requstParam, @ RequestBody List apps) {return new BaseResponse ();}

The latter transmission method is very strange when spring is parsed with @ RequestBody, but the previous paragraph is that the mobile phone APP has been released and cannot be modified, so it can only be modified at the back end to meet this strange demand.

Through debugging, it is found that the parameters passed by the interface at the front end of the latter are "[" abc "," def "] =" like this, x-www-form-urlencode is the data format of multiple kev-value pairs, so now there is no value only key, which can only be solved through string processing.

@ RequestMapping (value = "/ check_apps_version", method = RequestMethod.POST, produces = {"application/json" Charset=UTF-8 "}, consumes = MediaType.APPLICATION_FORM_URLENCODED_VALUE) @ ResponseBody public BaseResponse checkAppsVersionParams (HttpServletRequest request, ReqCheckAppsVersion requstParam, @ RequestBody String apps) {String body = request.getReader () .lines () .collect (Collectors.joining (System.lineSeparator () Return BaseResponse.success ();}

There are two ways, one is to parse post data into string format through @ RequestBody, and the other is to parse the entire original post data through HttpServletRequest. Then do string processing.

But in doing this test, we thought about whether there would be only value without key, that is, "= [" abc "," def "]".

The test result is that you can't HttpServletRequest to this post data with tomcat, but you can parse from HttpServletRequest to post data with jetty.

This may be the difference between tomcat and jetty, but it is not clear why. But our problem has finally been solved, and the biggest feeling is that our predecessors dug a hole and later buried it.

I hope I can pay attention to the robustness of the code in the future and avoid digging holes for others or myself.

About application/x-www-form-urlencoded coding

Colleagues encounter the problem of reading data from POST through the request object getInputStream on the servlet side, but can not read it, which is suspected to be the problem of tomcat. Check that Content-type is application/x-www-form-urlencoded, and it is estimated that it has been parsed into parameters. Sure enough, there was an operation of request.getParameter before he got the stream.

If you are familiar with servlet, this question should be regarded as common sense. It has nothing to do with containers, and all servlet containers behave like this. A few years ago, I encountered this problem when implementing a gateway proxy. At that time, jetty was used. It was found that the data from POST could not be read, and it was also encoded by application/x-www-form-urlencoded. Breakpoint tracking found that there was request.getParameter before obtaining the stream, the data would be parsed, and the subsequent data stream could no longer be read.

In section 3.1.1 of the servlet specification, there is a description of when POST data will be treated as 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.

It is clearly stated in the specification that when the request is met:

1) http/https

2) POST

3) Content-type is application/x-www-form-urlencoded

4) if the getParameter method is called, the data will be treated as the paramaters of the request and can no longer be read directly through the inputstream of request.

So this approach is followed by tomcat, jetty, and other servlet containers. But then again, why is application/x-www-form-urlencoded-encoded data parsed as parameter?

You can use GET or POST to upload data using http. If you use GET, you can only use the queryString form of uri. This will encounter the problem of length. Different browsers or server may support different lengths, so if the data to be submitted is too long, it is not suitable to use GET to submit.

With POST, you can either have queryString in uri or put data in body. Body content can be encoded in a variety of forms, among which application/x-www-form-urlencoded coding is actually based on percent-encoding coding of uri, so POST data using application/x-www-form-urlencoded and queryString are just different in form and essentially transfer parameters.

In tomcat's Request.parseParameters method, the application/x-www-form-urlencoded is judged, and the data in the body is parsed and populated into the parameters, so it is impossible to read the body by stream (unless you have not triggered the getParameter-related method).

Before HTML4, the only way to encode form data was application/x-www-form-urlencoded (which is now the default), because in the early days, the data submitted on web was also very simple, basically in the form of key-value, so there was no problem for forms to be encoded in application/x-www-form-urlencoded.

Thank you for reading! This is the end of this article on "how to use Spring to deal with x-www-form-urlencoded". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.