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. 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. 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. 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. 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
