CDV ❯ Unable to forward non 200 response header (404, 403, etc.) to error page defined in web.xml
-
Bug
-
Status: Closed
-
1 Critical
-
Resolution: Fixed
-
Sessions
-
-
hhuynh
-
Reporter: eellis00
-
October 07, 2008
-
3
-
Watchers: 4
-
November 07, 2008
-
November 03, 2008
Description
This scenario is easily reproducible by editing the web.xml in the Cart demo app.
$ vi ~/terracotta-2.7.0/tools/sessions/configurator-sandbox/tomcat5.5/9081/webapps/Cart/WEB-INF/web.xml
…
<servlet-mapping>
<servlet-name>carts_jsp</servlet-name>
<url-pattern>/cart</url-pattern> <!-- no longer /* -->
</servlet-mapping>
$ touch ~/terracotta-2.7.0/tools/sessions/configurator-sandbox/tomcat5.5/9081/webapps/Cart/error.html
- Now run the configurator without Terracotta. Hit 9081/Cart/foobarurl
- You’ll be forwarded to the newly created error.html
- Run it again with Terracotta hitting the same url and you’ll see the default Tomcat error screen
$ less +G ~/terracotta-2.7.0/tools/sessions/configurator-sandbox/tomcat5.5/9081/logs/localhost.
SEVERE: Exception Processing ErrorPage[errorCode=404, location=/error.html] java.lang.IllegalStateException: Cannot forward after response has been committed at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:313) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301) at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:363) at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:284) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at com.tc.tomcat55.session.SessionValve55.tcInvoke(SessionValve55.java:63) at com.tc.tomcat55.session.SessionValve55.invoke(SessionValve55.java:50) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:619)
Comments
Fiona OShea 2008-10-08
Eric Ellis 2008-10-08
Hi Tim and Taylor,
Just some quick background info on this issue. Basically, because of a very complicated unidirectional Apache proxy configuration (our IT contractors are Apache experts so I trust them) I’m unable to work around the 400, 404, 403, 500 error page redirects using Apache. My only other alternative would be to replace out the Tomcat errorReportValveClass (or equivalent) to display a more friendly default page. I know it’s been, literally years, but Ziff is finally ready to go live with Terracotta and this little issue is pretty much the last thing. Because rolling onto Terracotta is now holding up our release schedule management has decided to move forward with the default Tomcat error pages; though this is hardly the face that we’d like to put on our high volume corporate media sites. Is there any way you’d be able to give us an ETA on a patch for this?
Thanks in advance,
Lucas Nelson 2008-10-08
This one is preventing us from upgrading to 2.7 as well. This bug does not exist in 2.6.4, which is what I decided to start using 2 weeks ago when I hit this - initial implementation for us, had started on 2.7 snapshot0. I struggled to get a reproducible test case (perhaps because I was trying to use a jsp page as the error page), though it always failed in our full application, so a BIG thank you to Eric for sorting a test case out.
Fiona OShea 2008-10-21
P1 this as it is blocking a reference account from upgrading to 2.7.0 (Ziff) What will we have to lose in 2.7.1 to investigate this? Possible LOE of 3 days to investigate and fix according to Tim.
Tim Eck 2008-11-02
isCommitted() now matches what tomcat expects in this case
Tim Eck 2008-11-03
not quite fixed (for glassfish)
Tim Eck 2008-11-03
okay I believe this works in all of our supported containers now
Hung Huynh 2008-11-04
test existed
Tim can you take a quick look at this to see if we have a bug here?