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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [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
> > > >
> > >
> >
>
