HTTP Request (POST) field size limit & Request.BinaryRead in JSPs

Question

First off my Java is beyond rusty and I've never done JSPs or servlets, but I'm trying to help someone else solve a problem.

A form rendered by JavaScript is posting back to a JSP. Some of the fields in this form are over 100KB in size. However when the form field is being retrieved on the JSP side the value of the field is being truncated to 100KB.

Now I know that there is a similar problem in ASP Request.Form which can be gotten around by using Request.BinaryRead. Is there an equivalent in Java?

Or alternatively is there a setting in Websphere/Apache/IBM HTTP Server that gets around the same problem?

Answer 1

We have resolved the issue. Nothing to do with web server settings as it turned out and nothing was being truncated in the post.

The form field prior to posting was being split into 102399 bytes sized chunks by JavaScript and each chunk was added to the form field as a value so it was ending up with an array of values. Request.Form() appears to automatically concatenate these values to reproduce the single giant string but Java getParameter() does not. Using getParameterValues() and rebuilding the string from the returned values however did the trick.

Answer 2

Since the posted request must be kept in-memory by the servlet container to provide the functionality required by the ServletRequest API, most servlet containers have a configurable size limit to prevent DoS attacks, since otherwise a small number of bogus clients could provoke the server to run out of memory.

It's a little bit strange if WebSphere is silently truncating the request instead of failing properly, but if this is the cause of your problem, you may find the configuration options here in the WebSphere documentation.

Answer 3

You can use getInputStream (raw bytes) or getReader (decoded character data) to read data from the request. Note how this interacts with reading the parameters. If you don't want to use a servlet, have a look at using a Filter to wrap the request.

I would expect WebSphere to reject the request rather than arbitrarily truncate data. I suspect a bug elsewhere.