When using a form with a custom encoding (e.g. "multipart/form-data"), the content type is not restored after a redirect to a login page (auth-method = FORM). To reproduce: - A page that POSTs using multipart/form-data encoding (or anything other than application/x-www-form-urlencoded) to a result page that is protected by a login page (auth-method=FORM) is invoked. - Even though the multipart POST data exists (verified by reading input stream of request from result page) the content type of the request is always "application/x-www-form-urlencoded". - This only happens when redirected to the login page first. It does not happen if already logged in.
Created attachment 20152 [details] Multipart POST test case WAR To reproduce the bug: - Browse to the data entry page, e.g. http://localhost:8080/multipartposttest/ - Fill in some values (fields may be left blank, don't make file too big) - Press 'send this' button to submit form - A redirect to the login page will occur. Expects a user that has 'manager' role. - Results page shows some header values and request contents. Note the content type is "application/x-www-form-urlencoded" which is incorrect - should be multipart/form-data encoding. Everything else seems correct. - Go back to first data entry page using back button on browser and resubmit form. Because already logged in you will go directly to results page. - Note content type is now correct, e.g. "multipart/form-data; boundary=---------------------------187161971819895".
Created attachment 20153 [details] Patch for org/apache/catalina/authenticator/FormAuthenticator.java
Created attachment 20154 [details] Patch for org/apache/catalina/authenticator/SavedRequest.java
Looks like the cause could be due to org.apache.catalina.authenticator.FormAuthenticator class hardcoding the content type when restoring POST requests: L431: contentType.setString("application/x-www-form-urlencoded"); Created patch that saves the content type to the SavedRequest object and restores it when needed. This seems to fix the issue.
The fix has been applied to svn and will be included in 5.5.24 and 6.0.14. Many thanks for your patch.