Williams, Nick wrote:
So I read some code in org.apache.catalina.connector.Request.java. When parseParameters() is called, it
checks whether the Content-Type is "multipart/form-data" or
"application/x-www-form-urlencoded". If it's "application/x-www-form-urlencoded", it
checks to make sure that the Content-Length is not greater than maxPostSize.
That is probably because in that case, the body is not encoded, and the Content-length
matches the length of the posted data.
If it's "multipart/form-data", it delegates to another method, parseParts().
In parseParts(), the code begins looping over the parts and placing them into
the list of parts for the request. As it processes each part, it adds the size
(in bytes) of that part (including the part contents or file contents if this
is a file upload) to an aggregate post size variable. If at any point the
aggregate post size exceeds the maxPostSize variable, it fails.
This thus looks like it applies to the total size of the parts, after decoding the ones
that are Base-64 encoded (such as uploaded files contents).
Why the Content-Length is not checked, I am unsure. It seems it would be less expensive
to throw the exception before ever trying to parse the parts. However, this APPEARS to be
the functional equivalent of checking the Content-Length.
If it was using the global Content-length header, it would count not only the encoded data
bytes, but also the parts separators, headers etc..
So that's nice. It counts only the net data bytes, which is easier to compare to the size
on disk of a file that you would upload.
So, it would seem that maxPostSize does, indeed, affect file uploads, and that
if the total size of your request, including file parts, exceeds maxPostSize,
that the request will fail. Whether this behavior is consistent with that
specified in the spec, I am not an expert on that.
You've done a pretty good job so far, I believe.
What maybe is the difference here, is that you probably looked at the Tomcat 7 code, in
which I believe the FileUpload code has been integrated/merged.
Maybe in Tomcat 6 it is different, and when FileUpload is used, it doesn't count the
bytes, or doesn't pass the result back to Tomcat to match the MaxPostSize ?
Not that it matters, but this behavior is consistent with the land of PHP,
where a maxUploadFileSize value of 50MB does you no good if you forget to
increas your maxPostSize from the default of 5MB.
(Note: It's entirely possible that I'm reading the code wrong. I would suggest
that an experiment might solve this conclusively, but perhaps that has been
tried and I missed that somewhere in the chain.)
Nick
-----Original Message-----
From: André Warnier [mailto:a...@ice-sa.com]
Sent: Friday, December 14, 2012 1:15 PM
To: Tomcat Users List
Subject: Re: Does maxPostSize has an effect on file upload?
Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Chuck,
On 12/14/12 12:38 PM, Caldarale, Charles R wrote:
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject: Re: Does maxPostSize has an effect on file upload?
Does a file upload as multipart/form-data not count to the size of
the POST?
No, as the doc make clear.
I'm not so sure the docs make it clear.
I think you have to read the relevant RFC:
http://www.ietf.org/rfc/rfc1867.txt which is implicitly part of the
doc.
I'm not sure what part of that spec would apply.
Given the (Tomcat) documentation, one might reasonably believe that
the maxPostSize would refer to either the total Content-Length for an
application/x-www-form-urlencoded POST message or an individual
Content-Length of a single part of a multipart/form-data POST message.
The latter is not the case, and I think it's worth pointing that out.
Just a suggestion : maybe one of the Tomcat/Java gurus here could first explain
to what the maxPostSize attribute of the Connector really does relate ?
What /is/ being measured there ?
Is it, like, just the request's "Content-length" header, or is there a counter
which really counts the bytes being read e.g.
(and yes, obviously, if this is limited to an "application/x-www-form-urlencoded" POST, then it wouldn't be
just the Content-length header) (and, if it covers a "multipart/form-data" POST, then is it the total body
size, before of after decoding the Base-64 encoded bits ?) After all, this is a "Tomcat users" list, not a
"Tomcat dev" list; so we can't really expect the public here to go delve into the Java code to find out.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
This e-mail may contain privileged or confidential information. If you are not
the intended recipient: (1) you may not disclose, use, distribute, copy or rely
upon this message or attachment(s); and (2) please notify the sender by reply
e-mail, and then delete this message and its attachment(s). Underwriters
Laboratories Inc. and its affiliates disclaim all liability for any errors,
omissions, corruption or virus in this message or any attachments.
---------------------------------------------------------------------
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
