I haven't had a chance to test whether the request parameters are still available. Without the patch, the processActionForward() method will call doForward() if redirect="false" which calls RequestDispatcher.forward(). That will always fail if the wrapped request is used. Does it matter if getParameter() works or not in the actions that follow the first action? If that limitation exists I think it's preferable than getting an error.
Currently if the input attribute specified for the target after failed validation is an action or if you try to forward to an action from the first action execute method with redirect=false, then you get an error eventually after the actions execute method is called. After I submitted this patch, I thought it might not be the best way if anyone out there is extending RequestProcessor.java. Are there any struts extensions like Tiles or Velocity that extend that? If they are overriding doForward() or doInclude() then they need to be sure they unwrap the request before dispatching it. Hal > -----Original Message----- > From: Martin Cooper [mailto:[EMAIL PROTECTED]] > Sent: Sunday, April 21, 2002 12:49 AM > To: Struts Developers List; [EMAIL PROTECTED] > Subject: Re: multipart/form-data (bug?) or intended behavior? > > > Hal, > > With this patch, are the original request parameters still > available in the > target action or JSP? For a multipart request, the request > wrapper is where > the parameters are maintained so that request.getParameter() > and friends > work as usual. > > If that all works, could you enter a bug report in bugzilla > and attach your > patch to it? That will ensure that we don't lose track of it. > > Thanks. > > -- > Martin Cooper > > > ----- Original Message ----- > From: "Hal Deadman" <[EMAIL PROTECTED]> > To: "'Struts Developers List'" <[EMAIL PROTECTED]> > Sent: Friday, April 19, 2002 10:38 AM > Subject: RE: multipart/form-data (bug?) or intended behavior? > > > > The attached version of RequestProcessor.java fixed the multipart > > request forwarding issue that we were experiencing. Here is > the patch > > diff and I attached the old and new versions of > RequestProcessor.java. > > The patch just makes sure that the request is always > unwrapped before > > forwarding by moving the unwrap code to doForward() and > doInclude(). It > > could also just be added to processActionForward(). > > > > 534a535,539 > > > // Unwrap the multipart request (if any) > > > if (request instanceof MultipartRequestWrapper) { > > > request = ((MultipartRequestWrapper) > > request).getRequest(); > > > } > > > > > 568a574,578 > > > // Unwrap the multipart request (if any) > > > if (request instanceof MultipartRequestWrapper) { > > > request = ((MultipartRequestWrapper) > > request).getRequest(); > > > } > > > > > 932a943,945 > > > if (request instanceof MultipartRequestWrapper) { > > > request = ((MultipartRequestWrapper) > > request).getRequest(); > > > } > > 952,956d964 > > < // Unwrap the multipart request (if any) > > < if (request instanceof MultipartRequestWrapper) { > > < request = ((MultipartRequestWrapper) > > request).getRequest(); > > < } > > < > > 981,985d988 > > < // Unwrap the multipart request (if any) > > < if (request instanceof MultipartRequestWrapper) { > > < request = ((MultipartRequestWrapper) > > request).getRequest(); > > < } > > < > > 1058a1062 > > > > > > > > > > > -----Original Message----- > > From: Deadman, Hal [mailto:[EMAIL PROTECTED]] > > Sent: Friday, April 19, 2002 8:12 AM > > To: Struts Developers List > > Subject: RE: multipart/form-data (bug?) or intended behavior? > > > > > > 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] > > <mailto:[EMAIL PROTECTED]> > For additional > > > > commands, e-mail: < mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > > > -- > > To unsubscribe, e-mail: < > > mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: < > > mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
