> On Apr 24, 2015, at 4:02 PM, Vasicek, John <john.vasi...@disney.com> wrote:
>
> 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.
That's the way it works already. If it doesn't , we have a regression.
-- Leif
>
> 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.
>>>
>>
>>
>>
>
>
