> On Apr 12, 2015, at 4:28 PM, Alan M. Carroll wrote:
>
> This is in response to discussions on IRC and TS-3426. This would replace all
> of the current API functions to control cacheability.
>
> TSHttpTxnCacheablility
> ==
>
> Synopsis
>
>
> `#include `
>
>
> On Apr 24, 2015, at 4:02 PM, Vasicek, John 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. I
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"
wrote:
>Agree with Leif on clarifying explicitly
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.cach
> On Apr 12, 2015, at 5:28 PM, Alan M. Carroll 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:
