Our use case is rejecting the request based on IP. In the browser the status code is 0, and the network tab in developer tools is showing no response to the request. It's the same in Chrome and Firefox.
The request works fine when I send from Node.JS. It seems to me that Tomcat responds to the request before the upload has completed, and calling request.getParameter() fixes the problem because it causes Tomcat to read the full request before the response is sent. Some clients are fine with the early response (e.g. Node.JS), but both Chrome and Firefox don't like it. I'm not sure if it's an issue with how Tomcat handles the request, or how the browsers are handling the response (but I suspect it can be fixed on the Tomcat side as the problem does not occur with Payara). Thanks On 09/09/2019 15:48, André Warnier (tomcat) wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
