Description of problem: In particular scenarios, request.getContentType() incorrectly shows another header's value after FORM auth restores a request. Version-Release number of selected component (if applicable): How reproducible: In specific scenario Steps to Reproduce: 1. Deploy app with FORM auth (for example, the one attached) 2. Access app via ajp proxy. Using httpd, it helps to reproduce the issue with the following in place to force a content type header in the requests: RequestHeader set Content-Type application/x-www-form-urlencoded 3. Check the getContentType() return after following the redirect from j_security_check. The example app will spit this out. Actual results: getContentType() may return incorrect value Expected results: getContentType() returns correct value Additional info: This can occur if 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 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 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)
Created attachment 1248046 [details] bz1419145repro.zip
Verified with EAP 6.4.16.CP.CR1
Released on June 20 2017 as part of the EAP 6.4.16 maintenance release.