Incorrect content type seen after FORM authentication restores request

Environment

• JBoss Enterprise Application Platform (EAP)
  • 5.x
  • 6.x

Issue

• In some cases, we see Request.getContentType() return an incorrect value (null or another header's value) after FORM authentication completes and restores the original request.
• We see an exception like the followiing in resteasy after FORM authentication

WARN  [org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher] (ajp-localhost%2F127.0.0.1-8009-10) Failed to parse request.
java.lang.IllegalArgumentException: Failure parsing MediaType string: Keep-Alive
        at org.jboss.resteasy.plugins.delegates.MediaTypeHeaderDelegate.parse(MediaTypeHeaderDelegate.java:42)
        at org.jboss.resteasy.plugins.delegates.MediaTypeHeaderDelegate.fromString(MediaTypeHeaderDelegate.java:18)
        at javax.ws.rs.core.MediaType.valueOf(MediaType.java:173)
        at org.jboss.resteasy.plugins.server.servlet.ServletUtil.extractHttpHeaders(ServletUtil.java:90)
        at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:186)
        at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
        at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

Resolution

• If using AJP, try using HTTP as a workaround.
• Try to change the client so that it does not follow the redirect after j_security_check with a request including a content-type.

Root Cause

• This content is not included.BZ-1419145
• This can occur if the client request right before auth does not contain a request body and if the the client provides a content type header in the request when following the j_security_check redirect. It is also dependent upon coyote.Request.contentType() being called before the FormAuthenticator is reached. This results in the issue in the following manner:
  1. Client sends bodyless request that is prompted for authentication so no content type is set on the saved request. Client performs form auth successfully and follows redirect after j_security_check with a request including a content-type header
  2. coyote.Request.contentType() is called and stores a MessageBytes (contentTypeMB) for the content-type header
  3. FormAuthenticator is reached and recycles the coyote.Request's mimeheaders. The coyote.Request is then still referring to a MessageBytes instance with contentTypeMB, although with a null value.
  4. FormAuthenticator restores the saved request. This can result in the contentTypeMB MessageBytes instance being reset with a new value. Then subsequent calls to request.getContentType() may improperly return null or potentially the value from another header.
• Note that AJP is more prone to this since it inherently calls Request.contentType() in its prepareRequest(). But it could be seen still on HTTP if something also results in an early Request.contentType() call prior to FormAuthenticator (for instance if the RequestDumperValve is enabled)

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.