You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Gerolf Seitz <ge...@gmail.com> on 2007/12/20 22:14:34 UTC
WICKET-406: form fields are reset when a file upload fails
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
Re: WICKET-406: form fields are reset when a file upload fails
Posted by Gerolf Seitz <ge...@gmail.com>.
as i said, thinking out loud ;)
what you said was basically my idea:
submit the non-multipart form via ajax and do something like
target.appendJavascript("myForm.submit()");
this way we wouldn't even have to split the form into multiple forms.
but this could be problematic too: what about custom FormValidators that eg.
compare a form field value with
the uploaded file.
i haven't had the time to do research on how other webframeworks handle this
situation.
but given that we generally don't have a lot solutions to choose from,
we should decide whether we want to provide support for this.
Gerolf
On Dec 21, 2007 2:07 PM, Johan Compagner <jc...@gmail.com> wrote:
> how would you do that?
> Then it must be an ajax none multi part post first and then a none ajax
> multi part post after that?
>
> I dont see how you could redirect to the browser again and then post
> (without using some ajax and seperate forms)
>
> But still, users are building there own forms and layout so we have then
> to
> copy the values somehow
>
> This all looks like a major pittfall and trying to hit a very small nail
> with a huge hammer..
>
> johan
>
>
>
> On Dec 21, 2007 10:59 AM, Gerolf Seitz <ge...@gmail.com> wrote:
>
> > 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 < jcompagner@gmail.com> 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 <ge...@gmail.com> 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
> > > >
> > >
> >
>
Re: WICKET-406: form fields are reset when a file upload fails
Posted by Johan Compagner <jc...@gmail.com>.
how would you do that?
Then it must be an ajax none multi part post first and then a none ajax
multi part post after that?
I dont see how you could redirect to the browser again and then post
(without using some ajax and seperate forms)
But still, users are building there own forms and layout so we have then to
copy the values somehow
This all looks like a major pittfall and trying to hit a very small nail
with a huge hammer..
johan
On Dec 21, 2007 10:59 AM, Gerolf Seitz <ge...@gmail.com> wrote:
> 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 < jcompagner@gmail.com> 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 <ge...@gmail.com> 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
> > >
> >
>
Re: WICKET-406: form fields are reset when a file upload fails
Posted by Gerolf Seitz <ge...@gmail.com>.
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 < jcompagner@gmail.com> 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 <ge...@gmail.com> 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
> >
>
Re: WICKET-406: form fields are reset when a file upload fails
Posted by Johan Compagner <jc...@gmail.com>.
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 <ge...@gmail.com> 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
>