Reset @cache_control in Response when duplicating its instance

[ykitamura-mdsol]

Background

This must be a very rare case but we have experienced that when we changed a Cache-Control response header value of an endpoint (e.g. public -> private, no-store), the behavior of storing the response (this line) didn't change: https://github.com/rtomayko/rack-cache/blob/97819fb7cac8e80b5f2357400852cef49f088468/lib/rack/cache/context.rb#L254

Looks like this is happening.

When rack-cache is refreshing(updating) a cache, it makes a copy of an instance of Rack::Cache::Response class: https://github.com/rtomayko/rack-cache/blob/97819fb7cac8e80b5f2357400852cef49f088468/lib/rack/cache/context.rb#L238

and updates the cached headers including Cache-Control.

However, the value of the Cache-Control header is already memorized based on the old cache and copied to the Response instance on dup: https://github.com/rtomayko/rack-cache/blob/97819fb7cac8e80b5f2357400852cef49f088468/lib/rack/cache/response.rb#L68-L70

If a change made in the Cache-Control response header (e.g. public -> private, no-store), the header value rack-cache receives will be "private, no-store"

but rack-cache decides if cacheable or not based on the memorized value "public": https://github.com/rtomayko/rack-cache/blob/97819fb7cac8e80b5f2357400852cef49f088468/lib/rack/cache/response.rb#L102-L106

and the behavior of storing the response doesn't change.

Changes summary

As the title says, reset @cache_control in Response when duplicating its instance

[grosser]

nasty little bug, great digging! :D

[grosser]

1.12.1

[ykitamura-mdsol]

Thank you for the prompt release!!