> On Apr 12, 2015, at 4:28 PM, Alan M. Carroll <[email protected]> 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
