-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All,
I've filed this in Bugzilla: https://bz.apache.org/bugzilla/show_bug.cgi?id=64384 - -chris On 4/27/20 12:10, Christopher Schultz wrote: > Mark, > > On 4/27/20 12:02, Christopher Schultz wrote: >> Mark, > >> On 4/27/20 11:30, Christopher Schultz wrote: >>> Mark, > >>> On 3/30/20 16:51, Mark Thomas wrote: >>>> On 30/03/2020 21:45, Christopher Schultz wrote: >>>>> All, >>>>> >>>>> In my application under Tomcat 8.5.51, I have configured a >>>>> servlet to allow multipart/form-data submissions and I >>>>> have added this configuration as a part of the <servlet> >>>>> config: >>>>> >>>>> <multipart-config> >>>>> <max-file-size>1048576</max-file-size><!-- 1MiB --> >>>>> <max-request-size>1049600</max-request-size><!-- 1 MiB + 1 >>>>> kiB --> </multipart-config> >>>>> >>>>> Without the <multipart-config> section, the upload does >>>>> not work at all, so I know I have added this in the right >>>>> place. >>>>> >>>>> But I am able to upload files larger than 1MiB, and the >>>>> data is being given to the servlet. I was expecting an >>>>> error to be sent to the client (unlikely) or the data to be >>>>> suppressed from the servlet, or some kind of indication to >>>>> the servlet code that the upload was too big. >>>>> >>>>> The file I'm uploading as a test is 13658819 bytes, which >>>>> is greater than both 1048576 and 1049600. >>>>> >>>>> What am I missing, here? > >>>> Are you reading the request body directly? That will bypass >>>> the size checks. > >>>> If that doesn't explain it, I'd fire up a remote debugger, >>>> debug through an upload and see why the size checks are >>>> skipped. > >>> I finally had an opportunity to debug this. > >>> First of all, part of the problem was that Struts was >>> intercepting the call which made debugging a little confusing. >>> Tomcat was parsing the request, but it looked like Struts was >>> *also* trying to parse it, which ended up with a deeper tree >>> of wrapped request objects than necessary. > >>> Once I got Struts out of the way, I was able to determine that >>> every multipart part was being written to the disk, >>> temporarily, even the one-byte request parameters and stuff >>> like that. Yuck, and oops. > >>> That was happening because I had set no <file-size-threshold> >>> and so it defaulted to 0 bytes. > >>> Setting a <file-size-threshold> to something reasonable (I >>> chose 1024 bytes) ended up immediately having Tomcat reject my >>> known-too-large requests with HTTP 413 "Payload Too Large". > >>> So this is good: Tomcat is indeed complaining about the size >>> of the request. However, it didn't do it until I set a >>> non-zero <file-size-threshold>. This is my current >>> configuration in web.xml: > >>> <multipart-config> <max-file-size>1048576</max-file-size><!-- >>> 1MiB --> <max-request-size>1049600</max-request-size><!-- 1 MiB >>> + 1 kiB --> >>> <file-size-threshold>1024</file-size-threshold><!-- 1KiB --> >>> </multipart-config> > >>> With the <file-size-threshold> removed, Tomcat will happily >>> process a 30MiB file upload, which I didn't expect. > >>> I'm going to try to recreate this with a trivial web-app and >>> file a bug, because I don't think this is how it's expected to >>> behave. > >> Interestingly, specifying: > >> <file-size-threshold>0</file-size-threshold> > >> Causes things to work as expected as well. So it's not *merely* >> a zero file-size-threshold. It's specifically a missing one >> which causes the default to apply. > > - From the debugger, going up the tree from my servlet, I find the > multipartConfigElement that ends up being set on my servlet > wrapper has none of my configuration: > > multipartConfigElement MultipartConfigElement (id=545) > fileSizeThreshold 0 location "" (id=550) maxFileSize -1 > maxRequestSize -1 > > The code in WebRuleSet looks okay at first glance. > > -chris > -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6nDFkACgkQHPApP6U8 pFg3OxAAhvRIg8M3Db/1CvgjWhX+qD7O4uHJokH+DB8dN81m2IOg93xe7xASVO2v A/SLJYa0cynDyAAfzrEqutu4CmaPy+CpcQH9hgekk3+4vSpljdWKbBLFoXsuUrJ6 ns0U+JPvaHWpvjcAFopUrGeLNzBxeRl3fIuWDG3LKl+9vwE0l00esLNHQgsooQ/q H7nWfopYgiWEm8p0CJ9jxw7WnobxJzrEz49C43M1dPIrx2nK9WAWWVkevsM+yWIj 2jLW+FnxtKOQCEpEgkvJTrq3BYsHaUih85WH3vIUFr+uOAi2jCmstVENhEGo1GDW NswcHCkiD0bjejUOXA9Gx/erZ+8+w3nMzVej8ziRxYMFI4wroPwZzkpAyvNuUEWq 8FfTalKgKWOGgx5eMDG5NW3ndEFVzMdDxmZJpw8SBcav/k4ZlOQSIVU/J/8C9huC cPBkmsoWx0h2bdK08GUAP3a7SCGjXsVDV4nro60GL12++upDR+wDsEjAMWwn7x2H baJDSowjUb5kbJvcx3BsfhJgWTg/Zo8O234Xi+kiph64xFL+lZCfnQ3XqrK2j93c OcrHMZcbG1c77AN+RrQCItmYjScIPhGXApvqBBfgKzappGrX7AZDKrm3bxX8BxSN QgxMyy4Ya9JyHyQSeL1D7BexxY1sF8DW9+MqX9tO06kSFbuWSNo= =qh4+ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
