[
https://issues.apache.org/jira/browse/TS-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber closed TS-1439.
---------------------------
Resolution: Duplicate
> Replace functionality of 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
>
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)
