[
https://issues.apache.org/jira/browse/TS-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3663:
----------------------------------
Description:
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.
was:
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. But, 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 completely useless and should be
removed
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}
> Enhance redirect follow to allow storing each 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)
