tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mel Martinez <melaqu...@yahoo.com>
Subject Re: TC3.2.1 - response commit on included JSPs
Date Thu, 22 Feb 2001 04:25:51 GMT

--- Incze Lajos <incze@hbrt.hu> wrote:
> Maybe it's not correct in general but the JSP 1.1
> syntax
> contains the flush="true" attribute - obligatory in
> case
> of jsp:include. So, it's inconvenient but tomcat3 is
> an
> jsp 1.1 implementation. Am I missing something?    
incze

The JSP 1.1 spec says that the current response buffer
should be flushed _prior_ to the inclusion.  In other
words, the flush="true" requirement is talking about
what should happen at level of the calling page.  In
normal java servlet code this is saying :

if(buffered && flush==true){ //JSP1.1 flush always
true
  out.flush();
}
requestDispatcher.include(...);
//continue...

All this is saying is that, at least for JSP 1.1, we
are required to write everything we've put in the
buffer now before we add more to the buffer from the
included resource.  This requirement is supposed to
happen on the CALLING page, not in the INCLUDED page. 
I will note that TC3.2.1 does not actually do this
correctly and if it tried, it would break because of
the same root cause to the problem I am talking about
here.

The problem I am talking about is independent of the
_calling_ page.  

The problem is caused by the nature of the JSP servlet
that is generated by TC3.2.1.  It cannot properly be
included (dynamically) from either a JSP *OR* a
servlet because when it exits, it always sets the
isCommitted() flag of the response.  It should not do
that if the page is processing a request as an
'include' action because only the parent, calling
servlet or jsp should Commit the response.

As explained, the reason it always sets the
isCommitted() state is due to the sequence:

1) Every JSP page generated by TC3.2.1 has a finally{}
block that invokes out.flush() and...
2) For some reason the TC 3.2.1 JspWriterImpl
implementation of out.flush() commits the response
even BEFORE it calls response.flushBuffer()!
3) Also, out.flush() ALWAYS calls
response.flushBuffer() even if processing an included
request.

IMHO out.flush() should not commit the response.  Only
response.flushBuffer() should commit the response. 
And response.flushBuffer() should not be called from
an inside an 'include' request.

What probably SHOULD happen is the following:

1) Response.flushBuffer() alone should be used to set
the commit state.  But it should NEVER be called from
within an include action which can be checked with:

Obj incl = request.getAttribute(
         "javax.servlet.include.servlet_path");
if(incl==null){
  response.flushBuffer();
}

2) It is probably fine for out.flush() to be called at
the end of every JSP page.  Optionally, a check like
in
(1) could be used to call response.flushBuffer().

3) MOST IMPORTANTLY -> JspWriterImpl needs to be
rewritten so as to flush the output stream, but NOT to
commit the response and NOT to call
response.flushBuffer()!

I'd say that I consider this a serious bug because it
makes it impossible for a JSP page to be included in
any other JSP or even a Java Servlet except as the
last committment to the response - which means that it
is essentially only a 'forward' action.

Also, the fact that out.flush() (incorrectly) commits
the response actually means that technically TC3.2.1
can not be made compliant with the very spec you cite
because if it DID enforce the flush="true" attribute
and then tried to include a resource (or do ANY output
or forward or redirect), an error would occur becuase
(as I've stated) the response would already be
committed as soon as out.flush() got called.

"Fortunately", tc3.2.1 is currently broken in this
regard and is NOT actually flushing the output before
the include.  If the above problem in out.flush() is
fixed, then this should be fixed as well.

This bug has thrown a HUGE wrench into my current
project and I'm not sure how I'm going to address it
in the short term. 

Hasn't someone noticed this before?  Is this problem
fixed in either of the later versions (3.3 or 4.0)?

If so, I may need to upgrade and I really hate having
to upgrade to non-release versions of software since
that entails a whole lot of risk/justification I have
to explain to my clients.

Sigh... if it ain't one thing, it's another...

Mel


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/

Mime
View raw message