Can't this multi-part request forward problem be fixed by unwrapping the request
before doing RequestDispatcher.forward/include? All the methods in RequestProcessor
get the real request object from within the MultipartRequestWrapper before calling
doForward() or doInclude() except for processActionForward() which gets called after
action.execute().
I think the
if (request instanceof MultipartRequestWrapper) {
request = ((MultipartRequestWrapper) request).getRequest();
}
code should be moved to doForward() and doInclude() and removed everywhere else within
RequestProcessor. I will try this fix today. Probably won't work because it seems too
easy.
Hal
-----Original Message-----
From: Adam P. Jenkins [mailto:[EMAIL PROTECTED]]
Sent: Thu 4/18/2002 7:56 PM
To: Struts Developers List
Cc:
Subject: Re: multipart/form-data (bug?) or intended behavior?
Well, in your example scenario, you said that ActionOne first saves the
multipart data to a file, and then forwards to ActionTwo, so there's no
problem. When happens when a redirect forward is returned from an Action is
as follows:
- Struts sees that the redirect property of the ActionForward is true, so
instead of just calling the next action in the same request, it sends a
response back to the browser. The response contains a Redirect: header which
contains the URL for ActionTwo. The browser sees the Redirect header and so
makes a request for ActionTwo, this time with no multipart/form-data. The
new request gets passed by struts directly to ActionTwo.
Where the above would be a problem is if ActionOne did NOT handle the
multipart data, but instead forwarded to ActionTwo expecting ActionTwo to
handle the multipart data. Since a redirect causes a new request to be made,
any data in the current request is lost by the time ActionTwo gets called.
But since in this case ActionOne already handled the request, there's no real
problem.
Another example of where using a redirect forward is a problem is if your
action saves some ActionMessages or ActionErrors in the request and then
forwards, expecting the page being forwarded to to display the messages.
Since ActionMessages are stored in the request object, if you returned a
redirect forward from your action, the messages will be lost by the time the
next page gets the request.
Adam
On Thursday 18 April 2002 01:14 pm, you wrote:
> Thats a pretty dirty workaround if your multipart request contained a
> 5MB file being uploaded. Or what occurs in that case (when the browser
> makes the new request)?
>
> Rob
>
> Adam P. Jenkins wrote:
> > I believe another workaround is to set the redirect attribute on the
> > forward to true. E.g. the action config for ActionOne would have a local
> > forward like this:
> >
> > <forward name="nextaction" path="/action2.do" redirect="true"/>
> >
> > Then in ActionOne, when you return mapping.findForward("nextaction"),
> > this will cause the struts to send a redirect header to the browser
> > telling it to make a new request for action2. This works fine unless you
> > really wanted ActionTwo to have access to the same request attributes and
> > parameters as ActionOne.
> >
> > Adam
> >
> > On Thursday 18 April 2002 08:47 am, rob wrote:
> >>It's been this way since struts 1.0 (and likely prior to) but http
> >>requests carrying multipart/form-data posts result in an exception being
> >>thrown if forwarded through more than one action.
> >>
> >>(e.g request flow)
> >>
> >>1 - submit multipart/form-data request (with at least one file input)
> >> request is forwarded to ActionOne.
> >>2 - ActionOne handles multipart data, writes a file to disk does
> >> something with other parameters etc. then forwards to ActionTwo.
> >>3 - Exception is thrown.
> >>
> >>This occurs in the following versions I've tested 1.0.x, 1.1-b1. Copies
> >>of the exceptions follow this post.
> >>
> >>Workaround, never forward to a second action, always forward to a .jsp
> >>which must be the end point for the request after the first action.
> >>(This kind of sucks).
> >>
> >>If this is a bug then consider it submitted, if it's designed this way
> >>then how about changing it? (pretty please?)
> >>
> >>Thanks
> >>
> >>Rob
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]> For additional
> > commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
winmail.dat
Description: application/ms-tnef
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
