[
https://issues.apache.org/jira/browse/TS-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3663:
----------------------------------
Issue Type: New Feature (was: Improvement)
> 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: New Feature
> 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)
