[
https://issues.apache.org/jira/browse/TS-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14569967#comment-14569967
]
Sudheer Vinukonda commented on TS-3652:
---------------------------------------
Attaching the patch I tested to force redirect follow to use an already set
cache key (if set via API).
{code}
diff --git a/proxy/InkAPI.cc b/proxy/InkAPI.cc
index 41176ae..b164ca0 100644
--- a/proxy/InkAPI.cc
+++ b/proxy/InkAPI.cc
@@ -7215,6 +7215,7 @@ TSCacheUrlSet(TSHttpTxn txnp, const char *url, int length)
sm->t_state.cache_info.lookup_url_storage.create(NULL);
sm->t_state.cache_info.lookup_url =
&(sm->t_state.cache_info.lookup_url_storage);
sm->t_state.cache_info.lookup_url->parse(url, length);
+ sm->t_state.cache_info.is_api_lookup_url = true;
return TS_SUCCESS;
}
diff --git a/proxy/http/HttpSM.cc b/proxy/http/HttpSM.cc
index 0ed6640..108ad03 100644
--- a/proxy/http/HttpSM.cc
+++ b/proxy/http/HttpSM.cc
@@ -1544,7 +1544,11 @@ HttpSM::handle_api_return()
case HttpTransact::SM_ACTION_REDIRECT_READ: {
// Clean up from any communication with previous servers
release_server_session();
- cache_sm.close_write();
+ if (!t_state.cache_info.is_api_lookup_url) {
+ cache_sm.close_write();
+ } else {
+ DebugSM("http_redirect", "cache lookup_url set by API, do not close the
cache_sm");
+ }
// tunnel.deallocate_redirect_postdata_buffers();
call_transact_and_set_next_state(HttpTransact::HandleRequest);
@@ -4347,7 +4351,7 @@ HttpSM::do_cache_lookup_and_read()
// Changed the lookup_url to c_url which enables even
// the new redirect url to perform a CACHE_LOOKUP
URL *c_url;
- if (t_state.redirect_info.redirect_in_process)
+ if (t_state.redirect_info.redirect_in_process &&
!t_state.cache_info.is_api_lookup_url)
c_url = t_state.hdr_info.client_request.url_get();
else
c_url = t_state.cache_info.lookup_url;
@@ -4450,7 +4454,12 @@ HttpSM::do_cache_prepare_action(HttpCacheSM *c_sm,
CacheHTTPInfo *object_read_in
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;
+ if (t_state.cache_info.is_api_lookup_url &&
t_state.cache_info.lookup_url && t_state.cache_info.lookup_url->valid()) {
+ s_url->copy(t_state.cache_info.lookup_url);
+ DebugSM("http_cache_write", "[%" PRId64 "] update redirect info
original URL to lookup url %s", sm_id, s_url->string_get(&t_state.arena));
+ } else {
+ restore_client_request = true;
+ }
s_url = o_url;
} else {
o_url = &(t_state.cache_info.original_url);
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index 961d78b..fcb9f9d 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -1375,9 +1375,12 @@ HttpTransact::HandleRequest(State *s)
(if the host changed). Note DNS comes after cache lookup so in both cases
we do the DNS.
*/
if (s->redirect_info.redirect_in_process &&
s->state_machine->enable_redirection) {
- if (s->txn_conf->cache_http) {
+ if (s->txn_conf->cache_http && !s->cache_info.is_api_lookup_url) {
TRANSACT_RETURN(SM_ACTION_CACHE_LOOKUP, NULL);
} else {
+ // cache lookup already done for the original client request using api
cache lookup key
+ s->cache_lookup_result = HttpTransact::CACHE_LOOKUP_SKIPPED;
+ s->cache_info.action = CACHE_DO_WRITE;
TRANSACT_RETURN(SM_ACTION_DNS_LOOKUP, OSDNSLookup); // effectively
s->force_dns
}
}
diff --git a/proxy/http/HttpTransact.h b/proxy/http/HttpTransact.h
index fa64940..0408884 100644
--- a/proxy/http/HttpTransact.h
+++ b/proxy/http/HttpTransact.h
@@ -620,12 +620,13 @@ public:
CacheWriteLock_t write_lock_state;
int lookup_count;
SquidHitMissCode hit_miss_code;
+ bool is_api_lookup_url;
_CacheLookupInfo()
: action(CACHE_DO_UNDEFINED), transform_action(CACHE_DO_UNDEFINED),
write_status(NO_CACHE_WRITE),
transform_write_status(NO_CACHE_WRITE), lookup_url(NULL),
lookup_url_storage(), original_url(), object_read(NULL),
second_object_read(NULL), object_store(), transform_store(), config(),
directives(), open_read_retries(0),
- open_write_retries(0), write_lock_state(CACHE_WL_INIT),
lookup_count(0), hit_miss_code(SQUID_MISS_NONE)
+ open_write_retries(0), write_lock_state(CACHE_WL_INIT),
lookup_count(0), hit_miss_code(SQUID_MISS_NONE), is_api_lookup_url(false)
{
}
} CacheLookupInfo;
{code}
> During 3xx redirect follow, TS uses the redirect url as the cache key
> ignoring any cache key set via API
> --------------------------------------------------------------------------------------------------------
>
> Key: TS-3652
> URL: https://issues.apache.org/jira/browse/TS-3652
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Reporter: Sudheer Vinukonda
>
> Currently, during 3xx redirect follow, TS uses the redirect url (as received
> in the *Location* header of the 3xx response) as the cache key for storing
> the subsequent response to the redirect follow request. This works fine in
> most cases, since, the original client request would have cached the 3xx
> response and the final response would still be derived using the redirect
> follow url. This also allows direct requests to the redirect follow location
> be served from the cache efficiently.
> However, this is not desirable in some cases, especially when there's a TS
> API (plugin) modifying the cache key and wanting to store the final response
> against the modified cache key directly.
> Proposing to add a config setting to allow storing API set cache key during
> redirect follow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
