You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mel Martinez <me...@yahoo.com> on 2001/03/06 17:50:52 UTC

RE: HTTP Status Codes and Error Pages

Ethan,

You missed some good discussions on this two weeks ago
between Costin and myself!  :-)

Not only is it (premature commit) caused by the
RequestDispatcher.include() calling flushBuffer() but
there are other out.flush() calls in jasper that
contribute to the problem.

I don't know if it will or can be fixed in the 3.2.2
release (Mark?).  The RequestDispatcher.include() bug
is fixed in tc3.3. 

Costin - were you going to make the changes
(out.flush() -> out.flushBuffers()) in
JspParseEventListener.generateFooter() and
PageContextImpl.include() that we had discussed?  I
had thought that you implied you were going to do it
(that was before I was a committer) but I just noticed
that the out.flush() calls are still the same as
before.

Send me a note and I'll do this if you can't get to
it.

Mel

--- Ethan Wallwork <et...@net-linx.com>
wrote:
> Here is some more info on this problem.  I'm seem to
> be having some problems
> with the respnse getting committed too early.  It
> still seems wrong that an
> error page ever get returned with status code 200
> though.
> 
> 1) client makes request to Tomcat
> 2) Tomcat calls service() on my main servlet
> 3) servlet does an include() on some (possibly
> non-existant) JSP
> 4) JSP file does not exist (expected)
> 5) FileNotFoundException thrown from include()
> 6) main servlet catches exception
> 7) main servlet calls sendError()
> 8) sendError throws IllegalStateException (response
> already committed)
> 9) my error servlet gets called
> 10) error page get generated and sent to client with
> HTTP status 200 OK
> 
> The RequestDispatcher.include() method calls
> flushBuffer(), which commits the
> response.  This seems to mean that if you have a
> servlet which includes a JSP,
> any errors that occur can never be handled properly.
>  Yikes!
> 
> Code comments indicate that this flushBuffer() is
> not required by the spec, but
> is instead there to work around a problem with the
> session interceptor (BugRat
> bug #316).
> 
> --
> Ethan
> 
> -----Original Message-----
> From: Ethan Wallwork
> [mailto:ethan.wallwork@net-linx.com]
> Sent: Wednesday, February 28, 2001 1:03 PM
> To: Tomcat-Dev
> Subject: HTTP Status Codes and Error Pages
> 
> 
> 
> I can't tell if this is a bug or intended behavior:
> 
> I have a servlet that acts as the error page for my
> webapp.  Note that this is
> set up using the web.xml file, not the errorPage
> directive in the JSPs (if that
> makes any difference?)
> 
> When there is an error (say 500 Internal Server
> Error), it returns a WML page
> saying things went wrong.   This page is being
> properly generated, but the HTTP
> response code being sent along with it is "200 OK"!
> 
> The request attribute java.servlet.error.status_code
> is set to 500, as I would
> expect.  Calling response.setStatus(500) in the
> error servlet changes nothing.
> 
> This is the response I get, headers included:
> 
> HTTP/1.0 200 OK
> Content-Type: text/vnd.wap.wml;charset=UTF-8
> Cache-Control: no-cache
> Servlet-Engine: Tomcat Web Server/3.2 (final) (JSP
> 1.1; Servlet 2.2; Java
> 1.3.0; SunOS 5.8 sparc; java.vendor=Sun Microsystems
> Inc.)
> 
> <?xml version="1.0"?>
> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
> "http://www.wapforum.org/DTD/wml_1.1.xml">
> <wml>
> <card title="Error 500" id="error">
> <do label="Back" type="prev">
> <prev/>
> </do>
> <p>
> We're sorry, your request could be fulfilled.
> <br/>
> 500 Internal Server Error
> </p>
> </card>
> </wml>
> 
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email:
> tomcat-dev-help@jakarta.apache.org
> 
> 
> 
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email:
> tomcat-dev-help@jakarta.apache.org
> 


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

RE: HTTP Status Codes and Error Pages

Posted by cm...@yahoo.com.
> Costin - were you going to make the changes
> (out.flush() -> out.flushBuffers()) in
> JspParseEventListener.generateFooter() and
> PageContextImpl.include() that we had discussed?  I
> had thought that you implied you were going to do it
> (that was before I was a committer) but I just noticed
> that the out.flush() calls are still the same as
> before.

Well, 2 things happened - first I had to do the changes in
jasper ( i.e. jasper-runtime ), and make it available in
lib/common ( so I can cast JspWriter to JspWriterImpl - 
jasper.jar is not visible to serlvets/jsps )

Second, we are waiting ( Larry ? ) for a clarification,
to decide which is the best solution. 

The fix is trivial now - I tried on my machine and 
seemed to work fine ( i.e. pass the test suite ).

Costin



RE: HTTP Status Codes and Error Pages

Posted by Ethan Wallwork <et...@net-linx.com>.
I'll definitely have to look back in the archives.  I've been looking at 3.3
recently and discovered that the issue seemed to be fixed there, which makes me
happy :)

Is there a list of known problems in the latest tc3.3 milestone?  I may be able
to use this in our production systems, since our requirements are limited.
Tomcat 3.3 seems to do character encoding and jsp including better, which are
our two most used features.  I would love to know that things people know don't
work quite right in 3.3 yet.

Thanks for the reply!

--
Ethan

-----Original Message-----
From: Mel Martinez [mailto:melaquias@yahoo.com]
Sent: Tuesday, March 06, 2001 9:51 AM
To: tomcat-dev@jakarta.apache.org
Subject: RE: HTTP Status Codes and Error Pages


Ethan,

You missed some good discussions on this two weeks ago
between Costin and myself!  :-)

Not only is it (premature commit) caused by the
RequestDispatcher.include() calling flushBuffer() but
there are other out.flush() calls in jasper that
contribute to the problem.

I don't know if it will or can be fixed in the 3.2.2
release (Mark?).  The RequestDispatcher.include() bug
is fixed in tc3.3.

Costin - were you going to make the changes
(out.flush() -> out.flushBuffers()) in
JspParseEventListener.generateFooter() and
PageContextImpl.include() that we had discussed?  I
had thought that you implied you were going to do it
(that was before I was a committer) but I just noticed
that the out.flush() calls are still the same as
before.

Send me a note and I'll do this if you can't get to
it.

Mel

--- Ethan Wallwork <et...@net-linx.com>
wrote:
> Here is some more info on this problem.  I'm seem to
> be having some problems
> with the respnse getting committed too early.  It
> still seems wrong that an
> error page ever get returned with status code 200
> though.
>
> 1) client makes request to Tomcat
> 2) Tomcat calls service() on my main servlet
> 3) servlet does an include() on some (possibly
> non-existant) JSP
> 4) JSP file does not exist (expected)
> 5) FileNotFoundException thrown from include()
> 6) main servlet catches exception
> 7) main servlet calls sendError()
> 8) sendError throws IllegalStateException (response
> already committed)
> 9) my error servlet gets called
> 10) error page get generated and sent to client with
> HTTP status 200 OK
>
> The RequestDispatcher.include() method calls
> flushBuffer(), which commits the
> response.  This seems to mean that if you have a
> servlet which includes a JSP,
> any errors that occur can never be handled properly.
>  Yikes!
>
> Code comments indicate that this flushBuffer() is
> not required by the spec, but
> is instead there to work around a problem with the
> session interceptor (BugRat
> bug #316).
>
> --
> Ethan
>
> -----Original Message-----
> From: Ethan Wallwork
> [mailto:ethan.wallwork@net-linx.com]
> Sent: Wednesday, February 28, 2001 1:03 PM
> To: Tomcat-Dev
> Subject: HTTP Status Codes and Error Pages
>
>
>
> I can't tell if this is a bug or intended behavior:
>
> I have a servlet that acts as the error page for my
> webapp.  Note that this is
> set up using the web.xml file, not the errorPage
> directive in the JSPs (if that
> makes any difference?)
>
> When there is an error (say 500 Internal Server
> Error), it returns a WML page
> saying things went wrong.   This page is being
> properly generated, but the HTTP
> response code being sent along with it is "200 OK"!
>
> The request attribute java.servlet.error.status_code
> is set to 500, as I would
> expect.  Calling response.setStatus(500) in the
> error servlet changes nothing.
>
> This is the response I get, headers included:
>
> HTTP/1.0 200 OK
> Content-Type: text/vnd.wap.wml;charset=UTF-8
> Cache-Control: no-cache
> Servlet-Engine: Tomcat Web Server/3.2 (final) (JSP
> 1.1; Servlet 2.2; Java
> 1.3.0; SunOS 5.8 sparc; java.vendor=Sun Microsystems
> Inc.)
>
> <?xml version="1.0"?>
> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
> "http://www.wapforum.org/DTD/wml_1.1.xml">
> <wml>
> <card title="Error 500" id="error">
> <do label="Back" type="prev">
> <prev/>
> </do>
> <p>
> We're sorry, your request could be fulfilled.
> <br/>
> 500 Internal Server Error
> </p>
> </card>
> </wml>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email:
> tomcat-dev-help@jakarta.apache.org
>
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email:
> tomcat-dev-help@jakarta.apache.org
>


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org