[
https://issues.apache.org/jira/browse/TS-3680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3680:
------------------------------
Fix Version/s: 6.0.0
> 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
> Fix For: 6.0.0
>
>
> 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)
