[
https://issues.apache.org/jira/browse/FILEUPLOAD-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511018
]
Paul Benedict edited comment on FILEUPLOAD-140 at 7/8/07 5:44 PM:
------------------------------------------------------------------
Jochen, please re-evaluate this issue. The first link I sent you was my overall
objective, but it relates to another issue here:
https://issues.apache.org/struts/browse/STR-2700
On Windows and Sun machines, if there is about 20KB of text in a JSP after an
"exceeded" upload, the connection will hang indefinitely. This was tested on
multiple JDKs (4, 5, 6), application servers (Tomcat, Weblogic), and OS. We
tested with a Mac too but the issue did not exist.
My proposed solution is no more of an "invitation for DOS attacks" anymore then
transmitting a large text field. Data is data and frameworks don't see files
any different than other form field elements.
We patched Struts, but really the patch belongs in FILEUPLOAD as an option. We
could allow the developer the option to either choose a hanging socket or a
large upload. :-) I am definitely for the latter because it allows the request
to complete normally, even if it the response takes longer.
I rate this issue as a critical or blocker because, given the stated
conditions, the response is unable to be completed unless the workaround is in
place.
The hanging is caused by the input stream being full. The response is blocked
until the stream is finished. The issue should really be renamed "allow input
stream to exhaust" or something similar -- throwing away any other data before
returning.
was:
Jochen, please re-evaluate this issue. The first link I sent you was my overall
objective, but it relates to another issue here:
https://issues.apache.org/struts/browse/STR-2700
On Windows and Sun machines, if there is a about 20KB of text in a JSP after an
"exceeded" upload, the connection will hang indefinitely. This was tested on
multiple JDKs (4, 5, 6), application servers (Tomcat, Weblogic), and OS. We
tested with a Mac too but the issue did not exist.
My proposed solution is no more of an "invitation for DOS attacks" anymore then
transmitting a large text field. Data is data and frameworks don't see files
any different than other form field elements.
We patched Struts, but really the patch belongs in FILEUPLOAD as an option. We
could allow the developer the option to either choose a hanging socket or a
large upload. :-) I am definitely for the latter because it allows the request
to complete normally, even if it the response takes longer.
I rate this issue as a critical or blocker because, given the stated
conditions, the response is unable to be completed unless the workaround is in
place.
> Means to preserve text parameters when upload limit exceeded
> ------------------------------------------------------------
>
> Key: FILEUPLOAD-140
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-140
> Project: Commons FileUpload
> Issue Type: Improvement
> Affects Versions: 1.2
> Reporter: Paul Benedict
> Assignee: Jochen Wiedmann
>
> I am trying to resolve https://issues.apache.org/struts/browse/STR-2585 but
> am lacking the means to do it. The current use is with the deprecated
> DiskFileUpload and I prefer to have this class fixed first. When
> SizeLimitExceededException is thrown, it does not return the items it has
> collected thus far. I see two possible solutions which involve adding a
> property on the exception to return them:
> (1) Return the parameters thus gathered or
> (2) finish out the input stream but throw away all file items and return only
> the text parameters.
> Otherwise, whenever a the upload exceeds its limit, all other input
> parameters disappear.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
