On 09.09.2019 15:21, Leon Atherton wrote:
Thank you for the suggestion.
I have just tried playing with this value. Setting it to -1, and setting
it to 100x larger than the default.
In both cases, the behaviour seems unchanged.
Without touching this value, Tomcat will accept multipart POST requests
much larger than 2MB (which is the default) as long as you call
request.getPart() or request.getParameter().
I haven't tried that, but as per the documentation that at least looks wrong.
The problem I am seeing is that if a response is sent without calling
one of those methods, the browsers see it as a failed request.
To help me (or us) better understand the issue, could you provide a bit of
context ?
Such as : why would the client send content in a POST, if the service at the end of the
target URL is not going to read that content ?
What would be a use case ?
(Mainly because my interpretation is that, if the browser does that, then at least in some
way it /is/ a bad request, which /should/ fail).
And maybe another question : have you tried monitoring such a request/response using a
browser-based tracing tool, to show exactly what the server is sending back ?
(is it e.g. some kind of 4xx response ?)
Thanks
On 09/09/2019 12:59, André Warnier (tomcat) wrote:
Hi.
Did you check :
https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#Common_Attributes
--> maxPostSize
Note : normally, the browser will encode (Base64 or similar) the
content of a file and send the encoded content, which tends to be
significantly larger (in bytes) than the original file (say + 30%). I
do not know (and the doc does not say) if the maxPostSize attribute
refers to the POST content still encoded or already decoded.
On 09.09.2019 12:53, Leon Atherton wrote:
Hello,
I've discovered an interesting issue where POST requests fail when
uploading a file over about ~6MB if the server ignores the request
content.
I've put together a simple project to reproduce it:
https://github.com/leonatherton/tomcat-request-issue
Serverside code:
https://github.com/leonatherton/tomcat-request-issue/blob/master/src/main/java/DemoServlet.java
Clientside code:
https://github.com/leonatherton/tomcat-request-issue/blob/master/src/main/webapp/index.html
If you'd like to try it yourself there are a couple of pre-built war
files on the releases page, and there are steps to reproduce in the
README.md file.
The problem does not occur when uploading a small file, and the problem
can be "fixed" by simply getting a parameter from the request object. It
reproduces in Tomcat 8 & 9. The problem does not reproduce on Payara,
but I am seeing similar on Jetty.
My guess is that the server responds before the client has finished
uploading the file. The browsers see the incomplete upload and report
this as an error, despite content being sent in response. And my guess
is that inspecting a request parameter causes the server to wait for the
full upload before sending the response.
It's a slightly odd workflow, but it's not too unreasonable to sometimes
respond early and ignore the request content.
Is this expected behavior, or a bug in Tomcat?
Thanks!
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
