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
>

Reply via email to