On 11/23/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > You can't change HTTP headers (which is what is required to do a redirect) > from inside a RequestDispatcher.include() -- and that's what <jsp:include> > does under the covers.
Then what is flush="false" good for? I thought that the whole point is to wait sending response to client, allowing included resource to do its thing. Also, what about this sequence: response.reset(); response.sendRedirect(redirectURL); response.flushBuffer(); Should not it clean the [yet uncommitted] response, and set a proper header in it? > It would work with a static include (<%@ include> file="..." %>) though. Hmm... <jsp:include> definetely works in this setup: struts-config.xml: ----------------- <action path = "/main" forward = "/mainpage.jsp"/> mainpage.jsp: ------------ <%@ page contentType="text/html;charset=UTF-8" language="java" %> ... <jsp:include page="/login.do"/> ... struts-config.xml again: ----------------------- <action path = "/login" ... <forward name = "RELOAD" path = "/main.do" redirect = "true"/> <forward name = "VIEW" path = "/login-fragment.jsp"/> </action> You can see, that I dynamically include login.do action, it renders its view. Then I submit input directly to that action and redirect to main page... Oh, I see the difference now! In the working example I submit directly to included resource, while in non-working example I submit to the enclosing parent page. Duh! So the POST in the working example does not involve calling <jsp:include>. Still, I cannot get why it should not work with include, I thought that the whole point of flush="false" is to make it happen. If it is not for that, that what for? > Of course, redirect-after-post also seems like something you'd want to > implement in a controller somehow, not in every view. Yes, you are probably right. I am just trying things ;-) Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
