https://issues.apache.org/bugzilla/show_bug.cgi?id=49779
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Mark Thomas <ma...@apache.org> 2010-08-22 18:56:27 EDT ---
Thanks for the test case. As always, a simple ready to run test case makes
diagnosis a lot easier.
The root cause is a difference between what the HTTP specs say and what user
agents actually implemented with respect to handling 302 responses to POST
requests. RFC2616 tried to deal with this by adding the 303 response. Your test
case responds to the 302 with a POST (arguably in breach of the HTTP spec but
it does depend how you read it) which Tomcat isn't expecting so due to request
pipe-lining the POST data gets handled as part of the next request.
Tomcat's FORM authentication currently uses a 302 response for the redirect
stage. A 303 would make the expected client behaviour clearer but that would
only work for HTTP 1.1 clients. HTTP 1.0 clients would still be broken.
I therefore took the approach for Tomcat 7 of swallowing any request body sent
in response to the redirect since Tomcat will restore the original request (the
one made prior to the login form being received) including any request body
provided at that time.
I am leaning towards not back-porting this change to Tomcat 5/6 since the
implementation is consistent with the user agent behaviour.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
