You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@trafficserver.apache.org by Hiroaki Nakamura <hn...@gmail.com> on 2016/04/26 03:17:19 UTC

[Feature request] Add configs to ignore server Cache-Control: max-age and Expires

Hi all,

I would like to add configs to ignore server Cache-Control: max-age and Expires.
In my use case, I would like to let origin server administrators to
use just Cache-Control: s-maxage
to control whether the contents are cacheable.

I am planning to create a CDN service and I would like to simplify the
rule for contents to be cached
because I would like to reduce the time to support users (the origin
server administrators).

I created a patch
https://github.com/apache/trafficserver/compare/master...hnakamur:add_config_ignore_server_cc_max_age_and_expires?expand=1

This patch adds two configs below:

.. ts:cv:: CONFIG proxy.config.http.cache.ignore_expires INT 0
:reloadable:
:overridable:

When enabled (``1``), Traffic Server ignores any ``Expires``
headers from the server. This technically violates the HTTP RFC,
but simplifies the operation of web site administrators to control whether
or not contents are cached.
With combination with ``proxy.config.http.cache.required_headers = 2`` and
``proxy.config.http.cache.ignore_server_cc_max_age = 1``, only the value of
``Cache-Control: s-maxage`` is checked to determine the content is cacheable.

.. ts:cv:: CONFIG proxy.config.http.cache.ignore_server_cc_max_age INT 0
:reloadable:
:overridable:

When enabled (``1``), Traffic Server ignores any ``Cache-Control:
max-age`` headers from the server. This technically violates the HTTP RFC,
but simplifies the operation of web site administrators to control whether
or not contents are cached.
With combination with ``proxy.config.http.cache.required_headers = 2`` and
``proxy.config.http.cache.ignore_expires = 1``, only the value of
``Cache-Control: s-maxage`` is checked to determine the content is cacheable.

Can I send this patch as a pull request?

Best regards,
Hiroaki

Re: [Feature request] Add configs to ignore server Cache-Control: max-age and Expires

Posted by Sudheer Vinukonda <su...@yahoo-inc.com.INVALID>.

In general, most (if not all) Header modifications are encouraged to be done using plugin API.
ts_lua or header_rewrite are a couple of such plugins that are bundled in the repo to provide certain type of Header operations amongst other things, but, there are instances where people still write their own custom plugins for specialized use cases that are not generic enough to be included in header_rewrite/ts_lua.
Having said that, if your use case is common enough and is not easily possible to implement using the API, it might also be possible to include in the core. 
It seems to me that your requirement is possible to implement using a custom plugin where you can handle duplicate headers etc, but, I'll let others chime in.
You may open a pull request on github with your patch and request for comments/review.
Thanks,
Sudheer 

    On Thursday, May 12, 2016 11:17 PM, Hiroaki Nakamura <hn...@gmail.com> wrote:

 Thanks for your comment.

The following is my understanding of what you said.

For example, I will ignore the max-age parameter and limit s-maxage to 60.
If the response from origin server contains the headers like:

< Cache-Control: s-maxage=180, max-age=360

Then I modify headers in READ_RESPONSE_HDR_HOOK like:

< Cache-Control: s-maxage=60
< X-Cache-Control: s-maxage=180, max-age=360

The original value of the second Cache-Control to X-Cache-Control
and the value of the second Cache-Control is modified to "s-maxage=60".

In SEND_RESPONSE_HDR_HOOK, modify headers back to the original headers.

Here is a simplified implementation for the proof of concept.
It has limitation that it cannot handle multiple Cache Control Headers

```
function read_response()
  ts.server_response.header['X-Cache-Control'] =
ts.server_response.header['Cache-Control']
  ts.server_response.header['Cache-Control'] = 's-maxage=60'
  return 0
end

function send_response()
  ts.client_response.header['Cache-Control'] =
ts.client_response.header['X-Cache-Control']
  ts.client_response.header['X-Cache-Control'] = nil
  return 0
end

function do_remap()
  ts.hook(TS_LUA_HOOK_READ_RESPONSE_HDR, read_response)
  ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, send_response)
  return 0
end
```

However the renamed header name X-Cache-Control may collide with the original
headers. In my usecase, the origin servers are out of my control, so any header
names may be used.

And I think it is simpler to implement ignoring and limiting headers
in the Traffic Server
than modifying and restoring headers in a plugin.

After all, I think I will use my original modification as a private
patch to the Traffic Server.

Regards,
Hiroaki

2016-05-13 11:25 GMT+09:00 Sudheer Vinukonda <su...@yahoo-inc.com>:
> Hmm..it should be possible to do what you need with a plugin.
>
> For instance, going back to the solution you tried, perhaps you could
> instead of storing the CC headers in the Request context, rename them with
> custom names in the Response context (which should get cached) and rename
> them as required subsequently?
>
> "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."
>
>
>
> On Thursday, May 12, 2016, 7:14 PM, Hiroaki Nakamura <hn...@gmail.com>
> wrote:
>
> I tried and found that when I modify headers in
> TS_HTTP_READ_RESPONSE_HDR_HOOK,
> the cached object has those modified headers, so when the next time a
> request comes in,
> the cached response with the modified headers is served.
>
> This is not what I want. My requirement is to serve cached objects
> with the original headers.
> I think it cannot be done with a plugin.
>
> So here I propose my request for modification again.
>
>> 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).
>
> Please give me your feedbacks.
>
> Regards,
>
> Hiroaki

Re: [Feature request] Add configs to ignore server Cache-Control: max-age and Expires

Posted by Hiroaki Nakamura <hn...@gmail.com>.

Thanks for your comment.

The following is my understanding of what you said.

For example, I will ignore the max-age parameter and limit s-maxage to 60.
If the response from origin server contains the headers like:

< Cache-Control: s-maxage=180, max-age=360

Then I modify headers in READ_RESPONSE_HDR_HOOK like:

< Cache-Control: s-maxage=60
< X-Cache-Control: s-maxage=180, max-age=360

The original value of the second Cache-Control to X-Cache-Control
and the value of the second Cache-Control is modified to "s-maxage=60".

In SEND_RESPONSE_HDR_HOOK, modify headers back to the original headers.

Here is a simplified implementation for the proof of concept.
It has limitation that it cannot handle multiple Cache Control Headers

```
function read_response()
  ts.server_response.header['X-Cache-Control'] =
ts.server_response.header['Cache-Control']
  ts.server_response.header['Cache-Control'] = 's-maxage=60'
  return 0
end

function send_response()
  ts.client_response.header['Cache-Control'] =
ts.client_response.header['X-Cache-Control']
  ts.client_response.header['X-Cache-Control'] = nil
  return 0
end

function do_remap()
  ts.hook(TS_LUA_HOOK_READ_RESPONSE_HDR, read_response)
  ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, send_response)
  return 0
end
```

However the renamed header name X-Cache-Control may collide with the original
headers. In my usecase, the origin servers are out of my control, so any header
names may be used.

And I think it is simpler to implement ignoring and limiting headers
in the Traffic Server
than modifying and restoring headers in a plugin.

After all, I think I will use my original modification as a private
patch to the Traffic Server.

Regards,
Hiroaki


2016-05-13 11:25 GMT+09:00 Sudheer Vinukonda <su...@yahoo-inc.com>:
> Hmm..it should be possible to do what you need with a plugin.
>
> For instance, going back to the solution you tried, perhaps you could
> instead of storing the CC headers in the Request context, rename them with
> custom names in the Response context (which should get cached) and rename
> them as required subsequently?
>
> "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."
>
>
>
> On Thursday, May 12, 2016, 7:14 PM, Hiroaki Nakamura <hn...@gmail.com>
> wrote:
>
> I tried and found that when I modify headers in
> TS_HTTP_READ_RESPONSE_HDR_HOOK,
> the cached object has those modified headers, so when the next time a
> request comes in,
> the cached response with the modified headers is served.
>
> This is not what I want. My requirement is to serve cached objects
> with the original headers.
> I think it cannot be done with a plugin.
>
> So here I propose my request for modification again.
>
>> 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).
>
> Please give me your feedbacks.
>
> Regards,
>
> Hiroaki

Re: [Feature request] Add configs to ignore server Cache-Control: max-age and Expires

Posted by Sudheer Vinukonda <su...@yahoo-inc.com.INVALID>.

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px #715FFA solid !important; padding-left:1ex !important; background-color:white !important; } Hmm..it should be possible to do what you need with a plugin.
For instance, going back to the solution you tried, perhaps you could instead of storing the CC headers in the Request context, rename them with custom names in the Response context (which should get cached) and rename them as required subsequently? 
"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."

On Thursday, May 12, 2016, 7:14 PM, Hiroaki Nakamura <hn...@gmail.com> wrote:

I tried and found that when I modify headers in TS_HTTP_READ_RESPONSE_HDR_HOOK,
the cached object has those modified headers, so when the next time a
request comes in,
the cached response with the modified headers is served.

This is not what I want. My requirement is to serve cached objects
with the original headers.
I think it cannot be done with a plugin.

So here I propose my request for modification again.

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

Please give me your feedbacks.

Regards,
Hiroaki

Re: [Feature request] Add configs to ignore server Cache-Control: max-age and Expires

Posted by Hiroaki Nakamura <hn...@gmail.com>.

I tried and found that when I modify headers in TS_HTTP_READ_RESPONSE_HDR_HOOK,
the cached object has those modified headers, so when the next time a
request comes in,
the cached response with the modified headers is served.

This is not what I want. My requirement is to serve cached objects
with the original headers.
I think it cannot be done with a plugin.

So here I propose my request for modification again.

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

Please give me your feedbacks.

Regards,
Hiroaki

Re: [Feature request] Add configs to ignore server Cache-Control: max-age and Expires

Posted by Hiroaki Nakamura <hn...@gmail.com>.

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 <su...@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 <su...@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 <hn...@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 <su...@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

Re: [Feature request] Add configs to ignore server Cache-Control: max-age and Expires

Posted by Sudheer Vinukonda <su...@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 <su...@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 <hn...@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 <su...@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

Re: [Feature request] Add configs to ignore server Cache-Control: max-age and Expires

Posted by Sudheer Vinukonda <su...@yahoo-inc.com.INVALID>.

>>> 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 <hn...@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 <su...@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

Re: [Feature request] Add configs to ignore server Cache-Control: max-age and Expires

Posted by Hiroaki Nakamura <hn...@gmail.com>.

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 <su...@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

Re: [Feature request] Add configs to ignore server Cache-Control: max-age and Expires

Posted by Leif Hedstrom <zw...@apache.org>.

> On Apr 26, 2016, at 8:48 AM, Sudheer Vinukonda <su...@yahoo-inc.com.INVALID> wrote:
> 
> Can you pls create a jira with the requirement and proposed solution?
> Btw, reading the email, this seems like something that can be achieved via a plugin API.

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 ?

Cheers,

— leif

Re: [Feature request] Add configs to ignore server Cache-Control: max-age and Expires

Posted by Sudheer Vinukonda <su...@yahoo-inc.com.INVALID>.

Can you pls create a jira with the requirement and proposed solution?
Btw, reading the email, this seems like something that can be achieved via a plugin API.
Thanks,
Sudheer

On Monday, April 25, 2016 6:18 PM, Hiroaki Nakamura <hn...@gmail.com> wrote:

Hi all,

I am planning to create a CDN service and I would like to simplify the
rule for contents to be cached
because I would like to reduce the time to support users (the origin
server administrators).

I created a patch
https://github.com/apache/trafficserver/compare/master...hnakamur:add_config_ignore_server_cc_max_age_and_expires?expand=1

This patch adds two configs below:

.. ts:cv:: CONFIG proxy.config.http.cache.ignore_expires INT 0
:reloadable:
:overridable:

.. ts:cv:: CONFIG proxy.config.http.cache.ignore_server_cc_max_age INT 0
:reloadable:
:overridable:

Can I send this patch as a pull request?

Best regards,
Hiroaki