sure, you could do this, but then you're still wasting a potentially huge amount of resources.
let me think out loud a bit: what if we could separate the fileupload from the other form fields? we could then first submit the form values, redirect and then submit the multipart form. nested forms obviously won't work here. this could probably mean a lot of unforseen trouble and too much magic. Gerolf On Dec 21, 2007 1:21 AM, Johan Compagner < [EMAIL PROTECTED]> wrote: > Is it really imposible to not read in the request? > I guess not because to get the last param value, we need to read all > values. > But cant they be streamed to null? So at the moment the threshold is > passed we drop the byte array and just call read() in a loop without > doing anything with the result? > > On 12/20/07, Gerolf Seitz <[EMAIL PROTECTED]> wrote: > > hi folks, > > > > when the fileupload in a multipart form fails, other form fields that > are > > part of the form submission > > are reset (not preserved). > > the cause of this "misbehavior" is, that under certain scenarios (file > too > > big, invalid content type, ...), > > the MultipartServletWebRequest can't be created and thus the form field > > values can not be read from > > the HttpServletRequest. creating a normal WebRequest won't work, as the > > request parameters are encoded > > into the multipart part of the request. > > > > a possible (nasty) workaround (for eg. file size too big) could be > something > > like this: > > + try to create a MSWR with the desired maxSize > > + in case of failure, create a new MSWR with Bytes.MAX > > + parse the request, read & store the request parameters, read&discard > > uploaded files > > + mark the MSWR "invalid" so that users can't call getFile() (or > whatever > > it's called) > > > > the problem with this approach is, that somebody can possibly upload a > > Long.MAX_VALUE byte sized > > file and thus really compromise the server. > > this could be limited with an application setting "fallbackMaxSize", > which > > can be set by the user and > > is used instead of Bytes.MAX. > > > > > > i guess we have to decide whether we want to support this, or just leave > it > > as it's now. > > > > https://issues.apache.org/jira/browse/WICKET-406 > > > > wdyt? > > > > Gerolf > > >
