DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=39316>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39316 ------- Additional Comments From [EMAIL PROTECTED] 2006-04-15 00:28 ------- The size exception is thrown as soon as parseRequest() is called, because it is based on the HTTP header value. The actual parsing of the request never even starts. The delay you are seeing is a container issue, and not something either FileUpload or Struts can do anything about. I've already said that there is an open issue against Commons FileUpload to provide a better solution for aborted uploads, and this issue has been flagged as a duplicate of that issue. Unless you set sizeMax to -1, which is setting a Commons FileUpload parameter, there is no possible way for you to get partial results without changes to Commons FileUpload. It doesn't matter whether you're using Struts or something else - FileUpload still behaves that way. I'm afraid that if you want to know the finer details of how all this works, you are going to have to "track down" the FileUpload code. I frankly don't have the time to keep explaining it one paragraph at a time in the middle of an acknowledged enhancement request. But I will give you a hint: http://jakarta.apache.org/site/downloads/downloads_commons-fileupload.cgi -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
