Uploaded image for project: 'Undertow'
  1. Undertow
  2. UNDERTOW-322

HttpServletResponse#sendError() should operate on original unwrapped/unfiltered request

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 1.1.0.CR4, 1.2.0.Beta1
    • 1.0.15.Final
    • None
    • None

    Description

      HttpServletResponse#sendError() dispatches to the error page immediately as soon as the method is called. This is wrong and has disatrous consequences when called inside a running servlet and the error page is mapped to the same servlet. Undertow must wait until all filters/servlets have returned from their service and only then dispatch the request to the error page (all other containers like Tomcat, GlassFish, JBoss AS, Geronimo, etcetera have always worked that way for ages).

      Real world example: when the code executed by FacesServlet (JSF) calls sendError(), and the error page is a JSF page as well, then the request will be dispatched through the FacesServlet once again, causing all trouble in among others the threadlocal storage. Namely, when the sendError() returns, then all original threadlocal variables are lost, causing NPE over all place in the code running hereafter. JSF utility library OmniFaces tried to bypass this by putting the FacesContext back in TLS, but this is insufficient as JSF component libraries like PrimeFaces also have their own TLS variables: https://github.com/omnifaces/omnifaces/commit/b9badb86cb2112fd87485e060db21262de58887c

      Here's the relevant section from Servlet 3.1 specification (page 111; emphasis mine):

      10.9.3 Error Filters
      The error page mechanism operates on the original unwrapped/unfiltered request
      and response objects created by the container. The mechanism described in
      Section 6.2.5, “Filters and the RequestDispatcher” may be used to specify filters that
      are applied before an error response is generated.

      Attachments

        Activity

          People

            sdouglas1@redhat.com Stuart Douglas
            balusc@gmail.com Bauke Scholtz (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: