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);