-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6nAiIACgkQHPApP6U8 pFhmsBAAwavmRuXPmHO2at/cJTs4x21x+qMNT+qaJPA/O/KGnYr9x1zLSyCGq5vo JYMwp9zrS2mrgOTIXQCUdby0+DwLe/HovNaSDeyU8M7scMAJuOg4Td6DwtxcOtO+ AAbqIY1EE6hPBr3NkqVvhaAQCP4ITOojUE4RZhtTXIYjy16ekreFuJpUf/wJZAjY ptSwHKxE+KmLUU847jfts3qNaDnhTDnJ0BgeVfQSB3kmk8ZOfOW6FSFBMymrPrHv SEGNTOXqnuj7ki6ej98MIOpNQHoRle0cQmkOlKlYRwlvcVkSFWBKfwoeUeTKSvvL FrKk0ulbDVlVLCYQN2CL4V76iQenTYn3ngoc49yaoN1R8NrAmsJOuc+4vnkz/CUC bmAawKztStmYP/qE+WxFSreBwLiFBg7h7pQFQ5nIzBan8Js/ooyyWZlu9fCqbdmV 7o1qOw17NpRZETIli4v7doXJOqshrMY/bZfpM/p3Y/pTrOd+W1UxUdY0y2ggfmRJ +RU0foupVpk1BEN9VhSpSfJlfmasOdV84fq/M1xKLBmFspn5a5uLBwRtZvMntx1h qwsVjaMzmKFa77F6aGS4O1T9r4fDSdxcLAt66SXP1O/Pdds3qjvlMBps0pxOI7JJ 0gs4IdbRdT/3ApfjrvhQ6ZIfVVpoYioxW+zpaoF4s92rcIC2378= =fX7U -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
