Repository navigation
[Cache] cache control header handling #58
Description
currently, the CachePlugin does not cache when the no-store or private directive is active. however, we ignore no-cache. should we respect that one as well?
btw, not caching on the private header might be wrong. "private" means a shared proxy may not cache this. it depends on the scenario whether our client is a shared "proxy" or only for a single end user. (api calls with an api username would be single user and caching "private" should be fine).
maybe we should add an option to specify which headers are considered uncacheble, defaulting to all 3 of private, no-cache and no-store. users could then overwrite the default list with their things, possibly even work around no-store from a faulty server.
another thing is cookie handling: on a proxy, you never cache if there are Authorization or Cookie headers around, for fear of mixing up content. for a client this is less clear, depends on the scenario. might require another option on the plugin? or as joel proposes below, two separate plugins for the two different roles.
Activity
joelwurtz commentedon Feb 17, 2016
Maybe having 2 plugins would be best for that : a CacheBrowserPlugin, CacheProxyPlugin, where the defaults are corectly set for each use case ?
dbu commentedon Feb 18, 2016
they would simply differ by what default settings they propose? i think this would make sense for clarity, the roles are different and you need to understand rather a lot of caching if you need to set the right options manually.
joelwurtz commentedon Feb 18, 2016
I also think the code would be different, really not the same purpose and options for this two behavior, for me the actual implementation is closer to a Browser One.
And like you said, would be best to have a functional view before a technical one for each of the plugin we propose, so user would know which plugin for its use case without learning all the different options.
dbu commentedon Feb 18, 2016
not sure how much differences there really are. maybe we can at least
have an abstract base class for common functionality.
joelwurtz commentedon Feb 18, 2016
Sure, at least caching and restoring the response with stream is a bit special and can be abstracted, maybe we can provide a base cache class where we only have to write the cache decision logic and this may be used by the CacheStalePlugin (not sure if possible)