<jsp:include flush="false> response.sendRedirect problem

[carlisle411]

I am trying redirect to a specified URL via the following:

response.sendRedirect("http://foo.bar.com/");


Here is the actual code:


one.jsp
---------------------------------
<%@ page buffer="48kb" %>
<jsp:include page="two.jsp" flush="false" />


two.jsp
---------------------------------
<%@ page buffer="48kb" %>
<%
response.sendRedirect("http://foo.bar.com/");
%>


I know that this used to be a problem because the output buffer would
be flushed before the run-time file got included. But it is my
impression that this should now work with JSP 2.0. I thought I could
specify flush="false" in as a jsp:include attribute to have the output
stream NOT flushed.

For what its worth, I am using Tomcat 5.0.28 on a Mac. Anyone know
what the problem is? Workarounds? Thanks.

-j

 

[John C. Bollinger]

I am trying redirect to a specified URL via the following:

response.sendRedirect("http://foo.bar.com/");
Okay.

Here is the actual code:


one.jsp
---------------------------------
<%@ page buffer="48kb" %>
<jsp:include page="two.jsp" flush="false" />


two.jsp
---------------------------------
<%@ page buffer="48kb" %>
<%
response.sendRedirect("http://foo.bar.com/");
%>


I know that this used to be a problem because the output buffer would
be flushed before the run-time file got included.

If that were the behavior that doesn't necessarily make it a "problem".
In any case, JSP 2.0 does specify that one.jsp's buffer will not be
flushed prior to the inclusion if the flush attribute is "false".

I think I know what it is that you actually think is a problem: a
resource included by means of a jsp:include is not permitted to perform
a redirect. In fact, it is not allowed to change the response code in
any way, nor to set any response headers (including cookies). This is
explicitly stated in the JSP spec, is unchanged from earlier versions of
JSP, and is not directly connected to the issue of when the page buffer
is flushed.

But it is my
impression that this should now work with JSP 2.0. I thought I could
specify flush="false" in as a jsp:include attribute to have the output
stream NOT flushed.

The flushing (or not) part _does_ work, I am confident. That doesn't
mean that your redirection should work. I don't know about Tomcat 5,
but Tomcat 4 takes *active* measures to ensure that such redirections
don't work, regardless of whether or not the page buffer has been
flushed. If your JSP complied with the specification then you would
never know the difference.

For what its worth, I am using Tomcat 5.0.28 on a Mac. Anyone know
what the problem is? Workarounds? Thanks.

Don't redirect from a resource intended to be used by inclusion. Design
your application so that it is not necessary. If you have more specific
questions along those lines then we might be able to offer more specific
advice.

 

[Jeano]

a resource included by means of a jsp:include is not
permitted to perform a redirect. In fact, it is not allowed
to change the response code in any way, nor to set any
response headers (including cookies). This is explicitly
stated in the JSP spec

I looked into the spec. Sure enough:

"An included page cannot change the response status code or set
headers. This precludes invoking methods like setCookie. Attempts to
invoke these methods will be ignored. The constraint is equivalent to
the one imposed on the include method
of the RequestDispatcher class."

I guess now I am curious why? What is the reasoning behind not
allowinging jsp:include(d) pages to change the response status? Is
this somewhere in the spec too? If not, where can I find information
pertaining to this design consideration?

Thanks for the info, John.

-c

 

[Tilman Bohn]

In message <[email protected]>,
Jeano wrote on 28 Feb 2005 11:10:59 -0800:

[...]

I looked into the spec. Sure enough:

"An included page cannot change the response status code or set
headers. This precludes invoking methods like setCookie. Attempts to
invoke these methods will be ignored. The constraint is equivalent to
the one imposed on the include method
of the RequestDispatcher class."

I guess now I am curious why? What is the reasoning behind not
allowinging jsp:include(d) pages to change the response status?

The reason is that jsp:include only includes the _output_ of the
included page, not the code. Contrast this to the include directive
(JSP.1.10.3, since you're looking at the spec anyway), where the actual
code is included before the page gets compiled to a servlet. If you
need to set headers from an included page, use the latter instead of
jsp:include.

 

[John C. Bollinger]

I looked into the spec. Sure enough:

"An included page cannot change the response status code or set
headers. This precludes invoking methods like setCookie. Attempts to
invoke these methods will be ignored. The constraint is equivalent to
the one imposed on the include method
of the RequestDispatcher class."

I guess now I am curious why? What is the reasoning behind not
allowinging jsp:include(d) pages to change the response status? Is
this somewhere in the spec too? If not, where can I find information
pertaining to this design consideration?

Specifications are not in general strong on providing reasons for their
contents. It's not their purpose. My guess would be that the immediate
reason for the prohibition is that it provides for a clean (but not
required) mapping from the JSP standard action to servlet code, making
use of a RequestDispatcher. Of course, that begs the question of why
RequestDispatcher has the restriction.

I have always thought that the restriction makes sense. It prevents the
included resource from doing anything behind your back that you would
need to take account of. For instance, if the included resource sent a
redirect then the including page would be obliged to not write anything
further to the response -- but how is it supposed to know? There are
other, similar, considerations. All in all, though, a view of inclusion
that objects to the restrictions is just not the correct view.
Inclusion is not intended to be like using the resource as a
programmatic subroutine. It is more like using the resource as a
"web-level" subroutine.