I would like to see something that supports the ability to ³delete all
objects for a URI² - all objects/alternate objects for a URI, including
Content-Type, Content-Encoding, and the Vary header.
John Paul
On 4/12/15, 4:48 PM, "Sudheer Vinukonda" <sudhe...@yahoo-inc.com.INVALID>
wrote:
>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.
>>
>
>
>
