You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Susan Hinrichs (JIRA)" <ji...@apache.org> on 2015/06/09 20:57:00 UTC

[jira] [Created] (TS-3680) Refine options for handling post and follow redirect

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)