Agree with Leif on clarifying explicitly the interaction of the new API with
TSHttpTxnIsCacheable(). More specifically, should the new API also *override*
the global setting {{proxy.config.http.cache.http}} when it's disabled? The
current behavior only allows to override {{proxy.config.http.cache.http}} when
it's enabled (meaning, a Txn may disable cache when
{{proxy.config.http.cache.http}} is enabled, but, not vice-versa). This does
not seem consistent and I think that the new API should allow to override any
setting including the global setting (of course, as long as cache storage is
initialized). Does that make sense?
Thanks,
Sudheer
On Sunday, April 12, 2015 3:43 PM, Leif Hedstrom <zw...@apache.org> wrote:
> On Apr 12, 2015, at 5:28 PM, Alan M. Carroll <a...@apache.org> wrote:
>
> This is in response to discussions on IRC and TS-3426. This would replace all
> of the current API functions to control cache ability.
It’s in the Jira, but to be explicit, these are the three APIs that this new
API would deprecate:
TSReturnCode TSHttpTxnServerRespNoStoreSet(TSHttpTxn txnp, int flag);
void TSHttpTxnReqCacheableSet(TSHttpTxn txnp, int flag);
void TSHttpTxnRespCacheableSet(TSHttpTxn txnp, int flag);
We also have to be cognitive of how this interacts (or interferes) with the
TSHttpTxnIsCacheable() API, which asks if a specific request *would be*
cacheable.
But, +1 on this new API from me.
— Leif
>
> TSHttpTxnCacheablility
> ======================
>
> Synopsis
> ------------
>
> `#include <ts/ts.h>`
>
> .. c:function:: TSHttpCacheability TSHttpTxnCacheabilityGet(TSHttpTxn txnp)
> .. c:function:: TSReturnCode TSHttpTxnCacheabilitySet(TSHttpTxn txnp,
> TSHttpCacheabillity value)
>
> Control the cacheability of a transaction.
>
> Description
> ---------------
>
> Setting this value to something other than `TS_HTTP_CACHEABLE_DEFAULT`
> overrides any other setting or property of the transaction.
>
> The valid values are
>
> `TS_HTTP_CACHEABLE_ALWAYS`
> Cache the transaction if possible to store in the cache. Essentially this
>means if the request and the response are valid HTTP it will be cached.
> `TS_HTTP_CACHEABLE_NEVER`
> Do not cache transaction.
> `TS_HTTP_CACHEABLE_DEFAULT`
> Ignore this setting. Determine cacheablity according to the transaction and
>other settings.
>
> The iniital value is `TS_HTTP_CACHEABLE_DEFAULT`.
>
> For finer grained control it is expected the plugin will examine the relevant
> parts of the transaction and call this
> with the appropriate value to override the normal processing as desired. This
> must be called from the
> `TS_HTTP_READ_REQUEST_HDR_HOOK` to the `TS_HTTP_READ_RESPONSE_HDR_HOOK` hooks
> inclusive. After that the cache operation
> will have either started or can no longer be started.
>
