Leif Hedstrom created TS-1439:
---------------------------------
Summary: Deprecate TSHttpTxnNewCacheLookupDo
Key: TS-1439
URL: https://issues.apache.org/jira/browse/TS-1439
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Leif Hedstrom
Assignee: Phil Sorber
Fix For: 3.3.1
We have a set of APIs (in ts/experimtental.h) to do a "second" CacheSM / cache
lookup from a plugin API. This includes the API TSHttpTxnNewCacheLookupDo(). We
now also have a plugin that depends on this behavior, mostly as a side effect
(it wants the second cache lookup, but with the same cache key).
I think the implementation of this is rather unfortunate, having a second
CacheSM where you provide a second cache URL (to parse / MD5 etc.) to perform
this second lookup. It would be noticeably cleaner to be able to reuse the
CacheSM, and move the HttpSM back in the state chain, to retry a cache lookup
again. This would allow a plugin to retry cache lookups any number of times for
example, and also lets us unify on a single cache key API.
The latter is important for some of the changes I would like to do around the
cacheURL. Right now, we store (and set) the cache URL, which means that a
plugin who wishes to change the cache key has to create an artificial URL,
which gets parsed, and then turned into an MD5. We should eliminate this, and
provide Set/Get APIs to manipulate the (one and only) CacheSM's MD5 cache-key
directly from the APIs. This *could* be via a URL, but could be done on
whatever the plugin would prefer (e.g. an MD5 of a combination of the URL and
the request headers).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
