Bug 51653 - ServletRequestListener.requestDestroyed is called before request leaves a webapp
Summary: ServletRequestListener.requestDestroyed is called before request leaves a webapp
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 7.0.19
Hardware: PC Linux
: P2 major (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-12 06:01 UTC by wheleph
Modified: 2011-11-07 17:31 UTC (History)
0 users



Attachments
Sample webapp demonstrating the issue (4.33 KB, application/x-webarchive)
2011-08-12 06:01 UTC, wheleph
Details

Note You need to log in before you can comment on or make changes to this bug.
Description wheleph 2011-08-12 06:01:59 UTC
Created attachment 27379 [details]
Sample webapp demonstrating the issue

I use Tomcat 7.0.19, jdk 1.7.0-b147, Ubuntu Linux 11.04.

Steps to reproduce:
1. declare error page for 404 code in web.xml
2. Set location of that page to some servlet (let's call it ErrorServlet)
3. go to any invalid URL in webapp (to cause 404)
4. ErrorServlet is called after requestDestroyed on any registered listener.
This kind of behaviour is not correct in my opinion because it
contradicts to contract of ServletRequestListener.
Also it breaks org.springframework.web.context.request.RequestContextListener
if ErrorServlet uses session-scoped beans.

Description of the attached war file:
1. wheleph.RequestContextListener sets a local variable in requestInitialized and resets it in requestDestroyed
2. wheleph.SecondServlet writes to System.out the value of that variable thus showing whether it was called between requestInitialized and requestDestroyed or not. It's registered as 404 handler.
3. To reproduce the bug go to any invalid url (like http://localhost:8080/SpringListenerPOC/abcd) and see the message in log: 
"SecondServlet
in scope: false"

The relevant thread from dev.tomcat.apache.org:

On 09/08/2011 20:55, Volodymyr Sobotovich wrote:
> Hello, everyone.
>
> I think I have found a bug in Tomcat's lifecycle handling of
> ServletRequestListener. I'd like to discuss it here before posting.
> Tomcat 7.0.19, jdk 1.7.0-b147, Ubuntu Linux 11.04
> Steps to reproduce:
> 1. declare error page for 404 code in web.xml
> 2. Set location of that page to some servlet (let's call it ErrorServlet)
> 3. go to any invalid URL in webapp (to cause 404)
> 4. ErrorServlet is called after requestDestroyed on any registered listener.
> This kind of behaviour is not correct in my opinion because it
> contradicts to contract of ServletRequestListener.
> Also it breaks org.springframework.web.context.request.RequestContextListener
> if ErrorServlet uses session-scoped beans.
>
> What do you think about that. Should I post in to Bugzilla?

Hmm.

The error page handling is currently at the host level. One could argue
the listeners are being fired in the right place (when processing
enters/leaves the context). However, custom error pages defined by the
web app are currently outside the listener calls and that doesn't seem
right.

Addressing this would mean either:
a) moving the error handling to the context (inside the calls to the
ServletRequestListener) or
b) moving the calls to ServletRequestListener to the host level

I am leaning towards a) but wondering why things are the way the are
currently.

I'd suggest leaving this on the dev list for other folks to comment and
then add it to BZ in a couple of days unless the consensus is that it is
not a bug. The next 7.0.x release won;t be until early Sept so there is
plenty of time to get this right.

Mark

=======================================================================
Mark,

On 8/9/2011 4:35 PM, Mark Thomas wrote:
> Addressing this would mean either:
> a) moving the error handling to the context (inside the calls to the
> ServletRequestListener) or

+1

This just feels like the right state management level to me. Certainly
the default error handler can be called just as easily from this level
of the code.

-chris
Comment 1 Mark Thomas 2011-08-15 17:08:35 UTC
This has been fixed in trunk and 7.0.x and will be included in 7.0.21 onwards.
Comment 2 wheleph 2011-08-15 17:35:46 UTC
Thanks for the prompt fix! I think it's also worth including in Tomcat 6 which is widely used now because this seems to be inaccuracy in implementation of Servlet specification. How do you think?
Comment 3 Stephan Maminakis 2011-09-26 17:48:19 UTC
Mark,

I have just upgraded from 7.0.20 to 7.0.21 and I think this resolution has affected a very simple error page that I have had in my web app since Tomcat 5.  We have our own Realm which hits our Oracle database for the appropriate roles.

I have the following in my web.xml:

  <error-page>
    <error-code>403</error-code>
    <location>/badaccess.html</location>
  </error-page>
  ...
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>myadmin</web-resource-name>
      <description>My Admin Application</description>
      <url-pattern>/myadmin/*</url-pattern>
      <http-method>GET</http-method>
      <http-method>POST</http-method>
    </web-resource-collection>
    <auth-constraint>
      <description>System Administrators</description>
      <role-name>system_admin</role-name>
    </auth-constraint>
  </security-constraint>

The badaccess.html page lives in my web app (war) and simply displays a nice message to the user, letting him know he is going to an off-limits page.  Since I have upgraded to 7.0.21 this no longer works.  Instead, I get the standard Tomcat 403 error page.  Does the resolution to this issue require me to do something differently?  Again, this worked fine up until 7.0.20.

Thanks for any help,
Stephan
Comment 4 Konstantin Kolinko 2011-09-27 00:49:36 UTC
(In reply to comment #3)
> I have just upgraded from 7.0.20 to 7.0.21 and I think this resolution has
> affected a very simple error page that I have had in my web app since Tomcat 5.

You are correct that this fix broke error pages processing for certain error codes. In short, for errors that occur before request reaches Context.

It has already been noticed and fixed. Will be in 7.0.22. (See changelog).
Comment 5 Stephan Maminakis 2011-09-27 13:19:30 UTC
Thanks for the confirmation and the information update!

Stephan
Comment 6 Eitan Suez 2011-11-04 17:13:36 UTC
hello,
 i just upgraded a tomcat instance from v7.0.16 to v7.0.22.  the webapp in question uses spring security for login/authentication.  i noticed after upgrading that when triggering a logout using the spring-security-configured logout-url, i get this exception:

----------------------
SEVERE: Exception initializing page context
java.lang.IllegalStateException: Cannot create a session after the response has been committed
	at org.apache.catalina.connector.Request.doGetSession(Request.java:2758)
	at org.apache.catalina.connector.Request.getSession(Request.java:2268)
	at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:899)
	at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:229)
	at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:572)
	at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:517)
	at org.apache.jasper.runtime.PageContextImpl._initialize(PageContextImpl.java:146)
	at org.apache.jasper.runtime.PageContextImpl.initialize(PageContextImpl.java:125)
	at org.apache.jasper.runtime.JspFactoryImpl.internalGetPageContext(JspFactoryImpl.java:112)
	at org.apache.jasper.runtime.JspFactoryImpl.getPageContext(JspFactoryImpl.java:65)
	at org.apache.jsp.error_jsp._jspService(error_jsp.java:57)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:389)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:593)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:530)
	at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:450)
	at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:399)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:191)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:964)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515)
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1550)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)
----------------------

i narrowed down the version: 7.0.20 -- no exceptions
7.0.21 -- i get the above exception

my guess is that code changes relating to this issue somehow causes the spring security logout url (which the spring security LogoutFilter handles) to be interpreted as an error.  After the LogoutFitler sends a redirect, tomcat's handling of the "error" request is somehow mucking with session after the response was committed.

i wonder if the change introduced a bug or whether there's some configuration that perhaps i'm not doing properly on my end that could help me avoid this exception.
Comment 7 Pid 2011-11-04 21:01:37 UTC
Did you just pick a bug at random and add your comments?

Please join the Tomcat Users mailing list and ask for help there - Bugzilla is not a support forum.
Comment 8 Eitan Suez 2011-11-07 17:31:41 UTC
(In reply to comment #7)
> Did you just pick a bug at random and add your comments?
> 
no.

> Please join the Tomcat Users mailing list and ask for help there - Bugzilla is
> not a support forum.
ok; got it, thanks.