Hi all, I’d like to add this new API, TSHttpTxnIsCacheable(), as discussed on this Jira:
https://issues.apache.org/jira/browse/TS-1622 The reason for this API is for a specific plugin that I’m developing, a “Background Fetcher”, which listens for 206 responses from Origin, and replays them to allow the server to automatically fill the object in cache. This is discussed in somewhat in https://issues.apache.org/jira/browse/TS-974 (which talks about partial cache objects, but that turns out to be slightly more difficult). I have also filed a new Jira specifically for this plugin: https://issues.apache.org/jira/browse/TS-2554 I think there’s room for both solutions long term, hence I think this API fills a real need. In addition, I think this API is generally useful for any plugin that wants to try to do something clever upon detecting cache misses. I could imagine for example the page speed plugin to use this, and perhaps even the ESI plugin (but I have no real code examples for that). The new API is: tsapi int TSHttpTxnIsCacheable(TSHttpTxn txnp, TSMBuffer request, TSMBuffer response); The txnp argument is required, because the underlying code needs a txnp to get to the various configurations related to deciding upon cacheability. The request and response parameters are optional, a NULL value means to use the ‘default’ from the transaction, which equates to request -> the client request response -> the origin server response During discussions with James and Bryan, a concern is that we require the txnp, but I don’t see an easy way around that. Another concern was to be able to test cache ability for only a request (or a response) header. However, this is fairly easily done, and the reason why you can provide either of these yourself. It’s very easy to simply create a “dummy” response header, which has nothing but e.g. “200 OK\r\nCache-Control: max-age=31536000”, and use that as a simulated response. The Doxygen docs for the API is attached in the Jira above, and below as well. There are no ABI / API incompatibilities with this patch. Comments please. — Leif /** Test whether a request / response header pair would be cacheable under the current configuration. This would typically be used in TS_HTTP_READ_RESPONSE_HDR_HOOK, when you have both the client request and server response ready. @param txnp the transaction pointer @param request the client request header. If NULL, use the transactions client request. @param response the server response header. If NULL, use the transactions origin response. @return 1 if the request / response is cacheable, 0 otherwise */ tsapi int TSHttpTxnIsCacheable(TSHttpTxn txnp, TSMBuffer request, TSMBuffer response);