[jira] [Updated] (TS-3663) Enhance redirect follow to allow storing intermediate redirect responses

["Sudheer Vinukonda (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TS-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sudheer Vinukonda updated TS-3663:
----------------------------------
    Summary: Enhance redirect follow to allow storing intermediate redirect responses  (was: Enhance redirect follow to allow storing each intermediate redirect responses)

> Enhance redirect follow to allow storing intermediate redirect responses
> ------------------------------------------------------------------------
>
>                 Key: TS-3663
>                 URL: https://issues.apache.org/jira/browse/TS-3663
>             Project: Traffic Server
>          Issue Type: Improvement
>          Components: HTTP
>            Reporter: Sudheer Vinukonda
>            Assignee: Sudheer Vinukonda
>
> This is a follow up jira to TS-3661 and TS-3652.
> Basically, TS stores the final (2xx or any other status that is cacheable) response after all the redirect follow attempts against the original cache key (i.e remapped url from the client url or a modified cache key via API). 
> All the intermediate 3xx responses are never stored in the cache. There's a lot of confusing/misleading code that tries to build a new cache key with the Location header and tries to read/write the 3xx responses. All these read/writes fail, since, the cache_sm for the original key (remapped client request url or modified API key) still is open.
> Below are some snippets of code that are related:
> https://github.com/apache/trafficserver/blob/master/proxy/http/HttpSM.cc#L4450
> https://github.com/apache/trafficserver/blob/master/proxy/http/HttpSM.cc#L4350
> {code}
>     if (t_state.redirect_info.redirect_in_process) {
>       o_url = &(t_state.redirect_info.original_url);
>       ink_assert(o_url->valid());
>       restore_client_request = true;
>       s_url = o_url;
>     } else {
>     //......
> {code}
> {code}
>    if (t_state.redirect_info.redirect_in_process)
>     c_url = t_state.hdr_info.client_request.url_get();
>   else
> //....
> {code}
> After discussing further with [~bcall] and [~zwoop], we think that this could be made as an improvement to the current redirect follow behavior. Basically, extend the setting *proxy.config.http.redirection_enabled* to support a new option that stores intermediate redirect responses against a cache key that is set as the *Location* followed.
> Further to simply configuration (and to avoid confusion via multiple ways of doing the same thing), the setting *proxy.config.http.redirection_enabled* will be made overridable while deprecating the existing TS API *TSHttpTxnFollowRedirect*, since the config setting is sufficient to achieve the same behavior. This should be done regardless of this new feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)