[
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 each intermediate
redirect responses (was: Clean up cache key manipulations, unnecessary cache
read/writes during redirect follow)
> 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. 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)
