You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by "Alan M. Carroll" <am...@apache.org> on 2015/04/13 00:28:18 UTC
Proposed API: TSHttpTxnCacheabilitySet / TSHttpTxnCacheabilityGet
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 <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.
Re: Proposed API: TSHttpTxnCacheabilitySet / TSHttpTxnCacheabilityGet
Posted by Leif Hedstrom <zw...@apache.org>.
> On Apr 12, 2015, at 4:28 PM, Alan M. Carroll <am...@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 cacheability.
>
> 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.
I’ve been thinking about this some more, and in order to cover the existing three APIs (see Jira), I think we need more flexibility here. For example, the existing TSHttpTxnReqCacheableSet() is intended to make an otherwise uncacheable POST request cacheable. But at the same time, you want normal cache heuristics to apply.
In addition, I think some existing records.config settings can be encompassed in a generalization of the concept above, and we replace all these behaviors with one single records.config to act as a default beneath the API above. This also makes me think that maybe the API above is superfluous with a generic and overridable configuration?
My current thinking is that these enum’s would be bit fields, for example
typedef enum {
TS_HTTP_CACHEABLE_DEFAULT = 0,
TS_HTTP_CACHEABLE_ALWAYS = 1,
TS_HTTP_CACHEABLE_NEVER = 2,
TS_HTTP_CACHEABLE_ALLOW_POST_METHOD = 4,
TS_HTTP_CACHEABLE_EMPTY_DOC = 8,
TS_HTTP_CACHEABLE_IGNORE_CLIENT_NO_CACHE = 16,
TS_HTTP_CACHEABLE_IGNORE_CLIENT_MAX_AGE = 32,
TS_HTTP_CACHEABLE_IGNORE_SERVER_NO_CACHE = 64,
TS_HTTP_CACHEABLE_DYNAMIC_URLS = 128,
} TSHttpCacheabillity;
I haven’t looked super carefully at all possible configs / values here, so take this as a prototype / example. It’s possible too that we’d want to expand on this now (and in the future), and this seems like a possibly extensible feature as well (instead of adding more APIs and/or more configurations).
This would (I think?) eliminate the following (existing) records.config settings:
proxy.config.http.cache.post_method
proxy.config.http.cache.allow_empty_doc
proxy.config.http.cache.ignore_client_no_cache
proxy.config.http.cache.ignore_client_cc_max_age
proxy.config.http.cache.ignore_server_no_cache
proxy.config.http.cache.cache_urls_that_look_dynamic
We would replace this with one new config, with a default value of 184:
TS_HTTP_CACHEABLE_EMPTY_DOC |
TS_HTTP_CACHEABLE_IGNORE_CLIENT_NO_CACHE |
TS_HTTP_CACHEABLE_IGNORE_CLIENT_MAX_AGE |
TS_HTTP_CACHEABLE_DYNAMIC_URLS
The existing APIs would be replaced with setting following values from the enum (either in records.config or via an API, possibly overridable HTTP APIs):
TSHttpTxnServerRespNoStoreSet() -> TS_HTTP_CACHEABLE_NEVER
TSHttpTxnReqCacheableSet() -> TS_HTTP_CACHEABLE_POST_METHOD (mostly, but a combo)
TSHttpTxnRespCacheableSet() -> TS_HTTP_CACHEABLE_ALWAYS
Of course, there’s a large number of other possible setups that can now be expressed, which was not possible with either the old configs or APIs.
One major difference would be that setting e.g. TS_HTTP_CACHEABLE_NEVER in an early hook would effectively turn off the cache completely (early) before going to origin. I’ve tried turning off the cache in e.g. TS_HTTP_READ_CACHE_HDR_HOOK, but none of our APIs lets you (today) turn off the cache until we get the response back from origin (using TSHttpTxnServerRespNoStoreSet() ).
Question: If we were to do this, is there a value of having both a records.config setting, as well as the API above? What would the semantics be then ? The logical *or* of both bit-fields?
Cheers,
— Leif
Re: Proposed API: TSHttpTxnCacheabilitySet / TSHttpTxnCacheabilityGet
Posted by Leif Hedstrom <zw...@apache.org>.
> On Apr 24, 2015, at 4:02 PM, Vasicek, John <Jo...@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" <su...@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 <am...@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.
>>>
>>
>>
>>
>
>
Re: Proposed API: TSHttpTxnCacheabilitySet / TSHttpTxnCacheabilityGet
Posted by "Vasicek, John" <Jo...@disney.com>.
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" <su...@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 <am...@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.
>>
>
>
>
Re: Proposed API: TSHttpTxnCacheabilitySet /
TSHttpTxnCacheabilityGet
Posted by Sudheer Vinukonda <su...@yahoo-inc.com.INVALID>.
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 <am...@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.
>
Re: Proposed API: TSHttpTxnCacheabilitySet / TSHttpTxnCacheabilityGet
Posted by Leif Hedstrom <zw...@apache.org>.
> On Apr 12, 2015, at 5:28 PM, Alan M. Carroll <am...@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.
>