Page History

...

I'm breaking this proposal up into three sections, since it involves pretty invasive changes to not only the core, but also the elimination of an experimental API.

API additions

We will use the term "Key" or "Cache Key" to mean the original data (by default the URL) that externally identifies the object. The term "ID" will be used for the post-hash data used internally to identify objects in the cache.

A type to represent the post-hash data. This should include a data pointer (either void* or uint8_t*) and a size indicator (an enumerated type or a literal data length).

TSCacheID

The following APIs would be added:

  TSReturnCode TSHttpTxnCacheKeySet(TSHttpTxn txnp, void *data, size_t len);
  TSReturnCode TSHttpCacheKeySetTSHttTxnpCacheKeyUpdate(TSHttpTxn txnp, void *data, size_t len);
  TSCacheID* TSHttpTxnCacheIDGet(TSHttpTxn txnp);
  TSReturnCode TSHttpCacheKeyUpdate(TSCacheKeyGenerate(TSCacheID *result, void *data, size_t data_len);

The Set() API will perform the internal hashing function of the data, replacing the old cache key for the transaction completely. The Update() API will modify the currently active cache key, defaulted by the core as a hash of the remapped request URL, using by in effect appending the data provided to the original cache key. This is the best way to make incremental changes to the cache key, e.g. in a plugin implementing generation IDs over a set of URLs. IDGet() will return the result of hashing the key. Generate() exposes the hashing function. It computes the hash ID based on the input and stores it in the TSCacheID.

API removal

I'm proposing that we eliminate the 2nd cache state machine, and all the APIs related to this. This includes

...