Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache-Control header handling #3

Closed
sagikazarmark opened this issue May 4, 2016 · 12 comments · Fixed by #26
Closed

Cache-Control header handling #3

sagikazarmark opened this issue May 4, 2016 · 12 comments · Fixed by #26

Comments

@sagikazarmark
Copy link
Member

Q A
Bug? no
New Feature? yes

See php-http/plugins#58

@GrahamCampbell
Copy link
Contributor

👍

@dbu
Copy link
Contributor

dbu commented Aug 4, 2016

we do respect max-age. what is missing is a clearer role concept of how we handle s-maxage / private / no-cache / no-store instructions. as discussed in the other issue, we should probably have two plugins for the roles "single client / browser" and "caching proxy / shared cache". ideas for good names?

@Anahkiasen
Copy link

Any progress on this issue? Trying to use the plugin in the context of the php-github-api package but most (all?) Github responses return the private directive which makes the plugin skip caching :/

@dbu
Copy link
Contributor

dbu commented Jan 29, 2017

glad if you can work on it. i think the aproach of having two plugins for the two roles (cache proxy / personal cache) seems cleanest

@acrobat
Copy link
Contributor

acrobat commented Feb 18, 2017

I'm also running into this issue while caching github api responses. So I would like to put some work in to this, but how should we fix this?

Deprecate the general CachePlugin and have 2 new cache plugins for "single client" and "shared cache"? Or keep the currect CachePlugin and add the 2 extra caching type classes?

And if I understand correctly the only difference between the 2 new caching types will be the handling of private and no-store?

@dbu
Copy link
Contributor

dbu commented Feb 18, 2017

i think we mainly should add things to the $options to customize the behaviour. a config field for the list of cache-control directives should be respected, instead of the boolean in respect_cache_headers. for BC, we can rewrite respect_cache_headers=false to an empty list. the default value for respect_cache_headers should become the headers we currently look at.

once we have that, we can do a ClientCachePlugin and ServerCachePlugin that set the right defaults for respect_cache_headers, to make code more explicit. but people can also use CachePlugin directly for special situations. in #24 @tuupola is adding support to configure which request methods can be cached.

@php-http/owners what do you think of this approach?

@acrobat
Copy link
Contributor

acrobat commented Feb 18, 2017

Sound good to me! Let's see what @php-http/owners think about it, after that I will try to start work on it!

@tuupola
Copy link
Contributor

tuupola commented Feb 19, 2017

Would also be nice to have support for request cache headers. Currently they are ignored. For example when client sends request with Cache-Control: no-cache fresh content should be requested from the server.

@sagikazarmark
Copy link
Member Author

The options solution sounds like a good idea to me.

I am not sure about separate plugin classes though. If it's only about special construction, how about just having static constructors? CachePlugin::clientCache and CachePlugin::serverCache

@dbu
Copy link
Contributor

dbu commented Feb 19, 2017 via email

@acrobat
Copy link
Contributor

acrobat commented Feb 19, 2017

Ok, I will try to start WIP PR with the extra options and factory methods to setup specific caching so we can discuss things there with the code attached!

@acrobat
Copy link
Contributor

acrobat commented Feb 22, 2017

I've created #26 for fixing this issue. Please provide some feedback on this first version! Thanks!

acrobat added a commit to acrobat/cache-plugin that referenced this issue Feb 27, 2017
acrobat added a commit to acrobat/cache-plugin that referenced this issue Feb 27, 2017
@dbu dbu closed this as completed in #26 Feb 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants