I read the mail you refer to. I understand that I can achieve my requirement with the following steps:
1. In TS_HTTP_READ_RESPONSE_HDR_HOOK, remove Expires and Cache-Control: max-age headers and keep the values in the request context. 2. In TS_HTTP_SEND_RESPONSE_HDR_HOOK, restore Expires and Cache-Control: max-age headers with the values stored in the request context. I will try to implement this using the ts_lua plugin. Thanks for your help! 2016-04-27 1:08 GMT+09:00 Sudheer Vinukonda <sudhe...@yahoo-inc.com.invalid>: > Er..Sorry, I realize that email thread is doing the opposite of what you are > asking..but, nevertheless, the fact that CC headers can be modified during > READ_RESPONSE_HDR_HOOK and still impact the cache-ability of the response, > still holds and you can flip them the way you want. > > > > On Tuesday, April 26, 2016 8:58 AM, Sudheer Vinukonda > <sudhe...@yahoo-inc.com.INVALID> wrote: >>>> Can we specify whether a content is cacheable or not in >>>> TS_HTP_READ_RESPONSE_HDR_HOOK? > > Yes, I believe so - there are a couple of techniques mentioned in the below > email thread to do that..please give either a shot and let us know if it > works for your usecase.. > > http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201604.mbox/%3C976476209.1010737.1460066230963.JavaMail.yahoo%40mail.yahoo.com%3E > > > > > > > > > > On Tuesday, April 26, 2016 8:48 AM, Hiroaki Nakamura <hnaka...@gmail.com> > wrote: > > > > Thanks for your resonses. > > 2016-04-27 0:21 GMT+09:00 Leif Hedstrom <zw...@apache.org>: >> >>> On Apr 26, 2016, at 8:48 AM, Sudheer Vinukonda >>> <sudhe...@yahoo-inc.com.INVALID> wrote: >>> >>> Can you pls create a jira with the requirement and proposed solution? > > I created a jira issue. > https://issues.apache.org/jira/browse/TS-4386 > >>> Btw, reading the email, this seems like something that can be achieved via >>> a plugin API. > > I look into the diagram at > https://docs.trafficserver.apache.org/en/latest/developer-guide/plugins/hooks-and-transactions/index.en.html#hooks > > Can we specify whether a content is cacheable or not in > TS_HTP_READ_RESPONSE_HDR_HOOK? > > >> >> Agreed. Some thoughts has to be put into this, to make sure that we don’t >> provide yet another solution that has already support. I’m wondering if >> cache.config overlaps here too? The reason there is a >> “ignore-cc-from-client” records.config is because there’s no current support >> for that (other than e.g. header_rewrite plugin, which came after that >> records.config setting). >> >> I’m not opposed to the ignore-cc setting from origin, but we should discuss >> / analyze. Also, I’m not positive we want two configurations here, I.e. does >> it ever make sense to ignore the Cc: header but not the Expires header? The >> former supersedes the latter, and there’s also precedence logic here to >> consider. I think we should at a minimum reduce this to a single setting ? > > No, I don't need the separate two configs for my use case. > I would like to achieve using only Cache-Control: s-maxage and ignore > other headers to determine a content is cacheable. > > How about adding a value to proxy.config.http.cache.required_headers? > https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html#proxy-config-http-cache-required-headers > > 0 = no headers required to make document cacheable > 1 = either the Last-Modified header, or an explicit lifetime header, > Expires orCache-Control: max-age, is required > 2 = explicit lifetime is required, Expires or Cache-Control: max-age > 3 (new value) = explicit lifetime is required, Cache-Control: s-maxage > (Expires or Cache-Control: max-age are ignored). > > Best regards, > Hiroaki
