Susan Hinrichs created TS-3680:
----------------------------------
Summary: Refine options for handling post and follow redirect
Key: TS-3680
URL: https://issues.apache.org/jira/browse/TS-3680
Project: Traffic Server
Issue Type: Improvement
Components: HTTP
Reporter: Susan Hinrichs
In the current code base (5.3.x), the follow redirect feature applies to POST
methods as well as GET/HEAD methods. For POST redirects, the code saves aside
a copy (reference counted) of the post data, so it can resend it later if the
original server sends a redirect and the follow redirect feature is enabled.
This logic has been in there at least through the 5.x code probably earlier.
It has been pointed out that in some cases, replaying a POST in a redirect
scenario may not be safe. The POST may have already caused a change before the
redirect occurred.
In other cases, following the redirect on a post may be just fine. If the
origin server makes the redirect decision before anything is done on the post
request, replaying the post request should be just fine.
We should step back and determine if we want to reconsider how we handle follow
redirects for POST methods. I see the following options.
* Keep the current support and bug fix it as necessary (e.g. TS-3656)
* Remove the post redirect support.
* Add another config control to enable follow redirect only for GET/HEAD vs
enabled following redirect for all methods, vs do not follow redirect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
