Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > <jsp:include flush="false> response.sendRedirect problem

Reply
Thread Tools

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

 
 
carlisle411
Guest
Posts: n/a
 
      02-26-2005
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

 
Reply With Quote
 
 
 
 
John C. Bollinger
Guest
Posts: n/a
 
      02-27-2005
carlisle411 wrote:

> 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.

--
John Bollinger
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
Jeano
Guest
Posts: n/a
 
      02-28-2005

> 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

 
Reply With Quote
 
Tilman Bohn
Guest
Posts: n/a
 
      02-28-2005
In message <(E-Mail Removed) .com>,
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.

--
Cheers, Tilman

`Boy, life takes a long time to live...' -- Steven Wright
 
Reply With Quote
 
John C. Bollinger
Guest
Posts: n/a
 
      02-28-2005
Jeano wrote:

>>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?


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.

--
John Bollinger
(E-Mail Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Problem problem problem :( Need Help Mike ASP General 2 05-11-2004 08:36 AM



Advertisments