Cacheability Control

Problem  Multiple ways to control how a object interacts with the cache.  TSHttpTxnServerRespNoStoreSet  TSHttpTxnRespCacheableSet  TSHttpTxnReqCacheableSet  proxy.config.http.cache.http  Various options interact in unobvious ways.  Performance issues with when various controls can be set.

Proposal  Two control variables, READ and WRITE  Set/Get method for each.  Each has values of STANDARD, DISABLE, FORCE  STANDARD – Do the standard default ATS thing  FORCE – Do the operation if at all possible with no other validity checks  DISBABLE – Do not do the operation  TSHttpTxnIsCacheable(TSHttpTxn txnp, TSMBuffer* req, TSMBuffer* resp, uint64_t options)  As current function but can disable checks via options  E.g. METHOD, zero length document, required headers, etc.  Require at least one of req and resp arguments to not be NULL.

Use Cases  Revalidate – set READ to DISABLE  ATS does not try to read the cache but will go to origin and potentially cache that.  Serve stale content – set READ to FORCE  If the content is found in cache, serve it.  Cache POST – set WRITE to FORCE  Prevent caching of request – set WRITE to DISABLE  Serve from cache if valid, otherwise go to origin without caching response.  Do not interact with cache – set READ and WRITE to DISABLE  ATS will not serve from cache or cache response.

Final Extra Remarks Parent Proxy, remap, host resolution, etc.

Generalizing parent proxy and host resolution  Both parent proxy and host resolution are fundamentally about selecting a series of IP addresses to which to connect as the next hop.  HttpSM only needs to know about the current address and how to get the next one, rather than the complicated state manipulation currently in use.  Primary difference for parent proxy vs. not is the former can require multiple FQDN resolutions. May need to chain FQDN resolves.

Conceptual logic flow There is a a modification phase and then a service phase.

Isolate HttpSM We need to decouple the HttpSM from the operations and state transitions. HttpSM sends the request off to a resolver which returns a continuation that generates IP addresses. HttpSM tries the current address and if that doesn’t work it tries the next one. An open issue is how HttpSM provides feedback about connect failures.

Resolver internals Similar to the HostDB rewrite proposed earlier. Funtionally there is an FQDN extract which determines the FQDN of the next hop. This is passed down to the DNS layer which resolves the FQDN. The set of addresses is returned and can be further processed (e.g. round robin vs. failover vs. etc).

Open Issues  The internal structure of the resolver stack and how plugins can be use in this circumstance.  Forward vs. reverse proxy format (origin vs. proxy).  Feedback for failed connects.

Lifecyle hook for plugin alert

Lifecycle event TS_EVENT_LIFECYCLE_ALERT  Sent to all plugins on the lifecycle hook  Sent only by traffic_ctl  Similar to SIG_USR1 – just an alert to plugins  Plugins can do whatever in response such as check config file dates, reload, etc.  Painful but possible to pass commands by having plugin read command file when this is received.  Would be better to be able to pass a string with alert

Lifecycle hook TS_EVENT_LIFECYCLE_CONFIG  Quick sketch from conversation with Leif  Event when config file changes  Carries string that is a path that indicates the file set that was changed  config  config.remap  config.remap.include  Is this really different from the previous one?