[
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. 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}
was:
This is a follow up jira to TS-3661 and TS-3652.
> Clean up cache key manipulations, unnecessary cache read/writes during
> redirect follow
> --------------------------------------------------------------------------------------
>
> Key: TS-3663
> URL: https://issues.apache.org/jira/browse/TS-3663
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP
> Reporter: 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. 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}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
