前端POST请求参数过长，导致400错误解决办法及分析（转）

遇到在servlet端通过request对象getInputStream读取POST过来的数据，却读不到的问题，怀疑是tomcat的问题。查了一下Content-type是application/x-www-form-urlencoded，估计是被解析成了parameters，果然在他获取流之前，有过request.getParameter的操作。

---

熟悉servlet的话，这个问题应该算常识了。它其实跟容器无关，所有的servlet容器都是这样的行为。几年前在实现一个网关代理的时候就遇到过这个问题，当时使用的是jetty，发现POST过来的数据读不到，也是application/x-www-form-urlencoded编码，断点跟踪发现是在获取流之前有过request.getParameter，数据会被解析，并且后续数据流不可再被读取。
在servlet规范3.1.1节里，对POST数据何时会被当做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.

规范里已经明确的声明当请求满足: 1) http/https, 2) POST, 3) Content-type 是application/x-www-form-urlencoded, 4) 调用过getParameter方法；则数据会被当做请求的paramaters，而不能再通过 request 的 inputstream 直接读取。

所以不论tomcat、jetty还是其他servlet容器都遵循这个方式。不过话说回来，为什么application/x-www-form-urlencoded编码的数据会被当做parameter来解析呢？
使用http上传数据可以用GET或POST，使用GET的话，只能通过uri的queryString形式，这会遇到长度的问题，各个浏览器或server可能对长度支持的不同，所以到要提交的数据如果太长并不适合使用GET提交。

采用POST的话，既可以在uri中带有queryString也可以将数据放在body中。body内容可以有多种编码形式，其中application/x-www-form-urlencoded编码其实是基于uri的percent-encoding编码的，所以采用application/x-www-form-urlencoded的POST数据和queryString只是形式不同，本质都是传递参数。
在tomcat的Request.parseParameters方法里，对于application/x-www-form-urlencoded是有做判断的，对这种编码会去解析body里的数据，填充到parameters里，所以后续想再通过流的方式读取body是读不到的(除非你没有触发过getParameter相关的方法)。

在HTML4之前，表单数据的编码方式只有application/x-www-form-urlencoded这一种（现在默认也是这种方式），因为早期的时候，web上提交过来的数据也是非常简单的，基本上以key-value形式为主，所以表单采用application/x-www-form-urlencoded这种编码形式也没什么问题。

转载链接