Anyone have any thoughts on this? If not, lazy consensus will apply and I’ll pick one (which would be to promote TSHttpTxnCntl() and deprecate the overlapping APIs).
— Leif > On Oct 5, 2021, at 7:40 AM, Leif Hedstrom <zw...@apache.org> wrote: > > Hi all, > > While poking around, looking for a way to turn off logging for a single > transaction (to effectively sample logging activity), I stumbled upon this > API in experimental.h: > > tsapi TSReturnCode TSHttpTxnCntl(TSHttpTxn txnp, TSHttpCntlType cntl, void > *data); > > > The intent here was obviously to create a single, generic API to control > various behavior of a transaction. It currently only supports two such > controls: > > * Enabling / disabling logging (sm->t_state.api_info.logging_enabled) > * Retry intercept failures (sm->t_state.api_info.retry_intercept_failures) > > > There is currently no use of either of these in the core, except that the Lua > plugin supports both. I need the first one of these, and I see two options: > > 1. Promote TSHttpTxnCntl() from experimental to stable (i.e. move from > experimental -> ts.h). This API is very old, it’s likely been here forever. > > 2. Deprecate TSHttpTxnCntl(), and create two new APIs for Set() and Get() > of these respective “controls”. > > > I’m ok either way, but I think that if we promote TSHttpTxnCntl() to stable, > we should also consider deprecating the following APIs, and add the as > controls for TSHttpTxnCntl() instead: > > > tsapi void TSHttpTxnRespCacheableSet(TSHttpTxn txnp, int flag); > tsapi void TSHttpTxnReqCacheableSet(TSHttpTxn txnp, int flag); > tsapi TSReturnCode TSHttpTxnServerRespNoStoreSet(TSHttpTxn txnp, int > flag); // Maybe ?? > tsapi void TSHttpTxnDebugSet(TSHttpTxn txnp, int on); > tsapi void TSHttpSsnDebugSet(TSHttpSsn ssnp, int on); // Maybe ?? > tsapi void TSSkipRemappingSet(TSHttpTxn txnp, int flag); > > > If we do that, adding more of these controls (on/off) toggles to the API > would be done through TSHttpTxnCntl(). > > > Thoughts? > > — Leif
