-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6nA9sACgkQHPApP6U8
pFhX+A/8Dae5N3J+1lqeM2RgfQsj/Tp/oOzSNIoJO2420qwbcNe7XY896k1MnFMW
fEA6QE6M2GLmAwcpiZYwsw3xm2xzF3TRr8JYEwV2FDnETUylJ0kdDZQz7kiaxlMZ
7s/5/r69DnplUtHlx9/JBTOgICmxMbR2QMIKzGI2iaQpYHFkqoAR/h54IzTvlprF
XzUvPk0np2ZHADYn99JL7uLKr0UrBWqaxvY62LAg+GA0TrRQJKZs8ijjKkd0l1HA
D5gqZcZBqaANSv7q7ogCQGjqWK57gAyrAW2px1ySsH8XvdZCmn0Qbl10Wj9EhiZ3
a0lNpEBeMfizo2rz/+IOS8nxHmb+krjxK25AWXjwbyrG8zMR7X3L27MsqNVYFnCc
m0kmEAwk+Ly0o06MitZ9kcL5AvY8AkQQ9PoudjQRdx9QEqQw6irY6WT6wP6qaYVL
3nzX1dGc+yWdinngLe3AumP0uHYRqTI50JQ5RJs1w/F218jzskQGt8waswM1wNeB
kOsLNkxr3GErreuq3TiqMe0/f+Lof2bV2W63Gu+1lzy+hKtSsvsI2ZNGzMvB06TA
Le4GaqJHZkjGH64QJTprL94hSz96xtAhZfTipI+Y+5tNA48gYM5lOZH+e6PJHu9l
g4MDZpCUqsdPoZ8j7n7QaLM/b1ey2NQYDQt+SiPzN71XqbINrH4=
=cYyi
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
