These two days to do a good function to be online. But when the test suddenly found that when the amount of post submitted data, it will result in a backend 400 error. Initially, the bottleneck was assumed to be in Tomcat, because Tomcat could accept a POST request size of 2M by default, so manually modifying the Tomcat Server.xml file will accept post size modifications to unrestricted. After testing, the discovery still does not work. Today, the Internet to check the relevant information to solve this problem. The data is scattered and sorted out here to provide a solution for the same partners who have encountered the problem. Also for oneself later encounter this kind of question to make a note.
First look at the front end of the Content-type found is application/x-www-form-urlencoded and then based on this to find related issues, find the following article:
http://hongjiang.info/http-application-x-www-form-urlencoded/#comments
The introduction of a few words has played a big role:
A colleague encounters a problem that is not readable by a getinputstream reading a post over the servlet side through the request object, and is suspected of being tomcat. Check the Content-type is application/x-www-form-urlencoded, is estimated to be resolved into a parameters, and sure enough before he gets the flow, there have been request.getparameter operation.
If you are familiar with the servlet, this problem should be common sense. It has nothing to do with containers, and all servlet containers behave like this. A few years ago in the implementation of a gateway agent has encountered this problem, when the use of jetty, found that the post data can not read, but also application/x-www-form-urlencoded code, The breakpoint tracking discovery was request.getparameter before the stream was fetched, the data was parsed, and subsequent data streams could not be read again.
When the post data is described as parameters in the servlet Specification 3.1.1 Section:
1. The request is a 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 a initial call to any of the GetParameter family of methods on the Request object.
If the conditions are met, post form data would no longer be available for reading directly from the Request object ' s input Stream.
The specification has been explicitly declared when the request satisfies: 1 Http/https, 2 POST, 3) Content-type is application/x-www-form-urlencoded, 4) called the GetParameter method , the data is treated as the paramaters of the request, and can no longer be read directly through the InputStream of requests.
This gives me a great idea of post submission, but it's written in my spring MVC:
[java] View Plain copy/** * save counting record * * @param data * @return */ @ResponseBody @RequestMapping (value = "/savestorecheck", method = requestmethod.post) public ajaxresult savestorecheck (String data) { goodsjson materials = new gson (). Fromjson (data, inventorycheckin.class); inventorycheckin.setcheckid (Shopuuid.getuuid (Shopuuid.uuid_check)); inventorycheckin.setktvid (Shopconstutil.getshopid ()); try { string checkid = inventorycheckservice.savestorecheck (InventoryCheckIn); return Ajaxresult.getok (Checkid); } catch ( Inventorycheckexception | accesstolibraryexception | allotexception e) { return Ajaxresult.getlogicerror (E.getmessage (), ""); } }
In my opinion, the parameters that are actually passed along in this way are still spelled out like URL parameters. So when the length is too long, an error is caused. Therefore, the submission method Content-type modified to Application/json This JSON format, will not limit the size of the pass. Also, background reception needs to be modified. The code is modified to:
[java] View Plain copy/** * save counting record * * @param data * @return */ @ResponseBody @RequestMapping (value = "/savestorecheck", method = requestmethod.post,produces= "Application/json") public Ajaxresult savestorecheck (@RequestBody inventorycheck inventorycheckin) { inventorycheckin.setcheckid (ShopUUID.getUUID (ShopUUID.UUID_ CHECK)); inventorycheckin.setktvid ( Shopconstutil.getshopid ()); try {