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

Undertow allows session creation and session ID change after response is committed.

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Critical
    • 2.3.0.Final, 2.3.0.Beta1
    • 2.2.8.Final
    • Core
    • None

    Description

      The javadoc for HttpServletRequest.getSession(boolean) indicates:

      To make sure the session is properly maintained, you must call this method before the response is committed. If the container is using cookies to maintain session integrity and is asked to create a new session when the response is committed, an IllegalStateException is thrown.

      However, Undertow will happily create a new session, even if ServletResponse.isCommitted() returns true.  Sessions created after the response is committed cannot be referenced by any client (as we can no longer write a cookie to the response headers, nor encode the session identifier into the redirect location header) - and thus will remain in memory until they expire.  If this new session uses a maxInactiveInterval of 0 (or any negative value), this will cause a permanent memory leak (hence the critical priority). For the same reason, calls to HttpServletRequest.changeSessionId() should also throw an ISE if the response is committed.

      I suggest changing Undertow's default behavior to throw an ISE - in compliance with the servlet spec - but add a DeploymentInfo property to allow applications to tolerate this behavior (for compatibility reasons). This is best handled within Undertow directly, rather than requiring this condition to be handled by individual SessionManager implementations.

      Attachments

        Issue Links

          Activity

            People

              pferraro@redhat.com Paul Ferraro
              pferraro@redhat.com Paul Ferraro
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: