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

Discussion in 'Java' started by carlisle411, Feb 26, 2005.

  1. carlisle411

    carlisle411 Guest

    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
     
    carlisle411, Feb 26, 2005
    #1
    1. Advertising

  2. 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
     
    John C. Bollinger, Feb 27, 2005
    #2
    1. Advertising

  3. carlisle411

    Jeano Guest


    > 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
     
    Jeano, Feb 28, 2005
    #3
  4. carlisle411

    Tilman Bohn Guest

    In message <>,
    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
     
    Tilman Bohn, Feb 28, 2005
    #4
  5. 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
     
    John C. Bollinger, Feb 28, 2005
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andreas
    Replies:
    6
    Views:
    3,245
    Andrea Desole
    Feb 15, 2005
  2. Jeano
    Replies:
    5
    Views:
    7,326
    Orilg
    Oct 13, 2010
  3. ohaya
    Replies:
    0
    Views:
    4,128
    ohaya
    Jun 30, 2005
  4. Replies:
    1
    Views:
    826
    chris brat
    Jun 2, 2006
  5. Replies:
    0
    Views:
    1,251
Loading...

Share This Page