Bug 42361 - POST content type incorrect for multipart forms after login
Summary: POST content type incorrect for multipart forms after login
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 6.0.10
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-08 16:06 UTC by Peter Runge
Modified: 2007-05-08 17:05 UTC (History)
0 users



Attachments
Multipart POST test case WAR (2.70 KB, application/octet-stream)
2007-05-08 16:17 UTC, Peter Runge
Details
Patch for org/apache/catalina/authenticator/FormAuthenticator.java (1.16 KB, patch)
2007-05-08 16:22 UTC, Peter Runge
Details | Diff
Patch for org/apache/catalina/authenticator/SavedRequest.java (543 bytes, patch)
2007-05-08 16:23 UTC, Peter Runge
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Runge 2007-05-08 16:06:35 UTC
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.
Comment 1 Peter Runge 2007-05-08 16:17:52 UTC
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".
Comment 2 Peter Runge 2007-05-08 16:22:20 UTC
Created attachment 20153 [details]
Patch for org/apache/catalina/authenticator/FormAuthenticator.java
Comment 3 Peter Runge 2007-05-08 16:23:19 UTC
Created attachment 20154 [details]
Patch for org/apache/catalina/authenticator/SavedRequest.java
Comment 4 Peter Runge 2007-05-08 16:28:21 UTC
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.
Comment 5 Mark Thomas 2007-05-08 17:05:25 UTC
The fix has been applied to svn and will be included in 5.5.24 and 6.0.14.

Many thanks for your patch.