friendsofsymfony/foshttpcachebundle

Use the FOSHttpCache library in your Symfony projects

foshttpcachebundle's Issues

Make tags header configurable

The default X-Cache-Tags should be overridable in the bundle’s config.

Move regex calculation to DI class

As mentioned here.

Support for ETag

some sort of mapping (annotations, xml etc) to define how to compute an etag from an object. this might require param converters.

rails/rails@ed5c938

split into FOSHttpCache and FOSHttpCacheBundle?

actually the whole code about cache invalidation is not specific to symfony, but could run without. maybe it would make sense to split everything non-symfony into a component and have the bundle just provide the DI configuration and the request listeners and similar symfony related functionality.

now would be a good time to do that, as the namespace changes are a BC break for everybody anyways. doing it later would be a pain as we would change namespaces.

Refresh annotation

An annotation to refresh paths/routes is still missing:

• either @Refresh
• or add a refresh param (default = false) to invalidateRoute and invalidatePath; this option is cleaner and has my preference.

Add ConfigurationTest

Support invalidation with Symfony reverse proxy

Although Varnish makes more sense for any serious caching, it could be nice to support the Symfony reverse proxy as well, for out of the box caching.

Note: There is now a kernel provided in this bundle to support the user context with the reverse proxy. But no cache invalidation as of yet.

This issue is an archive of the original discussion. See HttpCache label issues for a list of all topics.

Do console event as well for CacheManager flush

http://symfony.com/doc/current/components/console/events.html#the-consoleevents-terminate-event

probably we can just add a method to the InvalidationListener that forwards to the right internal method.

• Update InvalidationListener
• Update documentation where it says you need to flush on console. The only case where flush won't happen automatically is when a fatal error / die is encountered.

CacheControlSubscriber

setting the no-cache header replaces all other cache headers. instead we should add a no-cache instruction. we could also check if max_age or s_maxage are > 0 and throw an error in that case (in configuration validation) as it makes no sense.

https://github.com/ddeboer/FOSHttpCacheBundle/blob/master/EventListener/CacheControlSubscriber.php#L148

configuration reference

the documentation should contain a configuration reference interlinked with a chapter on each feature that introduces to the why and how with minimal configuration examples. like the symfony and symfony cmf doc does with the Reference section and the chapters in the "Bundles" section. for us, it could be "Features" and "Configuration" i think.

see also the discussion in #92

Change the property visibility to private

Currently, everything uses protected properties in the bundle. This means that all properties are potential extension points, and a change on them will be a BC break.

As we want to follow semver, I think we should rather use the private visibility for properties and switch to protected only for places where we decide to expose a supported extension point. This will make thing easier to manage BC. A request to increase the visibility will need to be justified with a use case for the extension point (allowing us to decide whether it is the right way to provide such extension point).

Note that this rule will be common for our users, as it is the rule applied in Symfony itself.

what do you think about it ?

[Test] Missing test for FlashMessageListener

create a unit test for the flash message listener

• no session started if none yet
• no cookie set if no flash messages
• cookie set when we have flash messages.

Handle exceptions onKernelTerminate / onKernelException

we should try-catch exceptions in the InvalidationListener to avoid breaking the response, but make sure they get logged by having a listener for Events::PROXY_RESPONSE_ERROR and Events::PROXY_UNREACHABLE_ERROR.

Configuration setting for tag listener

Options:

• true: enable our TagListener if SensioFrameworkExtraBundle's ControllerListener is available and throw error otherwise.
• false: do nothing.
• auto (default?): only enable TagListener if ControllerListener is available.

As discussed in #2.

Make debug header configurable

There’s no way to override the default X-Cache-Debug.

configuration rule doc: match on client ip

i guess this is meant for when no caching is active. we could explain in the doc how to actually have the original ip in the request and not the varnish ip => http://symfony.com/doc/current/components/http_foundation/trusting_proxies.html - and explain that if the response depends on the client ip you most likely need to prevent proxies from caching it

Make configuration more verbose

Add some info() to Configuration.php.

Support Nginx cache invalidation

This Nginx module adds purge handling to Nginx.

context hash invalidation listener

once #57 is done, we should look into a logout listener to invalidate cached context hash requests.

Allow override of request cache headers

In our app we'd like to control all http caching using FOSHttpCache, we've found that some bundles add default cache headers that we would like to override.
It would be nice to have a global setting like:

force_header_overwrite: true | false

Or even a way of overriding just for one rule:

fos_http_cache:
    cache_control:
        rules:
            # only match login.example.com
            -
                match:
                    host: ^login.example.com$
                headers:
                    cache_control: { public: false, max_age: 0, s_maxage: 0, last_modified: "-1 hour" }
                    vary: [Accept-Encoding, Accept-Language]
                    force_overwrite: true | false

If this is something that is useful to the community I can implement it and do a PR.

[user context] check security context

figure out if we need to make the security context optional for sites that do not have a firewall over all routes:

#57 (diff)

Move bundle to FOS

Checklist:

• remove repositories from composer.json
• remove @dev
• remove 'work in progress' from readme and repo description
• check FOSHttpCache for links to the bundle. e.g. doc/conf.py

Manually set caching headers are overwritten

Our CacheControlSubscriber overrides any caching headers the user may have set manually ($response->setMaxAge() etc.), except in the case of Vary. @dbu Is this intended behaviour? If so, we should document it clearly.

remove hard dependency on guzzle

guzzle is only used with the varnish invalidator. we should move that from require to suggest and check in the DI extension if varnish is activated if guzzle is available.

annotation documentation expression language

i fear that the expression language example in the annotation doc are wrong. the TagSubscriber only passes in request and response, but not the parameters to the method that was called. if we can manage to provide the named parameters, that would be awesome. otherwise we should change the examples to use the request object.

i also got the impression that * @Tag(expression="'news-'~article.id") mentioned in
http://foshttpcachebundle.readthedocs.org/en/latest/tagging.html#invalidate-tags will not work. for me, expression language did not behave like twig, i had to write article.getId().

Add Nginx configuration

The bundle is still geared primarily towards Varnish. Let’s change this so it becomes possible to configure Nginx, too.

varnish command flexibility

we just merged a PR on LiipCacheControlBundle to make our varnish helper more flexible. we should port that over along with merging the rest of things.

liip/LiipCacheControlBundle#40

The CacheManager should depend on UrlGeneratorInterface

The CacheManager does not need the full RouterInterface so it should typehint the smaller interface

investigate security context on route without firewall

check if this is an issue or not: #57 (comment)

custom criteria for cache header rules

we could try to make the caching header configuration extensible, for example for this use case: symfony-cmf/content-bundle#36

purge vcl

in https://github.com/ddeboer/FOSHttpCacheBundle/blob/master/Resources/doc/varnish.md#purge we say to also purge on cache miss. after being confused, i assume that this is to still purge variants if the requested url was not matched? if that is correct, we might put a note there.

Release Tasks

• Depend on friendsofsymfony/http-cache: 1.* and remove the @dev
• Add a CHANGELOG.md file saying that this is the initial release
• Update todo in Resources/doc/overview.rst
• Deprecate LiipCacheControlBundle in favor of this, and provide a gist or something how to migrate from LiipCacheControlBundle liip/LiipCacheControlBundle#45
• PR on http://symfony.com/doc/current/cookbook/cache/varnish.html to advertise this bundle ;-) and maybe even http://symfony.com/doc/current/book/http_cache.html

Doc issues

Please add any doc issues to this list, so we don’t forget about them and we can fix them later in one go.

• Fix dot in table
• Improve introduction on index
• 'One line description of project.'
• search code for "todo"
• Check if we cover all features.

Convert EventListeners to EventSubscribers

@ddeboer said in #42: We should also standardize whether we user EventListeners or EventSubscribers (we now have both). EventSubscribers are easier to configure, but are tied closer to Symfony because they have to implement EventSubscriberInterface. Which do you prefer?

and i think going for subscriber sounds right to me.

Support REST controller invalidation

Add a controller annotation and YML configuration option that invalidate all methods in a controller when they and their routes names follow a convention, such as the of the FOSRestBundle.

Vary cache per user role

The CacheAuthorizationListener listener returns immediately after Symfony's security check for HEAD requests. Currently, it returns an empty response. We can make the listener more useful, though, by returning a hash based on the user's roles. That hash can then be set as a custom header. If the caching proxy is then configured to vary on that header, different responses for different user roles could be cached. Additionally, you'd still be sure each user only sees content that he has access to (because of Symfony's security check).

The user hash should be definable by the user. Perhaps from configuration (include_role or something?) but preferably by throwing an event (build_user_hash or something) that the user can add a listener for. This bundle then has its own listener with some sane defaults.

This idea is inspired by the very nice context aware caching in ez Publish. But whereas their solution requires a Varnish module to be installed (CURL), I think our solution will work with plain VCL restart.

Cannot install using composer

Hi,
When I use your command (composer require friendsofsymfony/http-cache-bundle:@stable) to install the bundle, it shows the error:

Problem 1
- The requested package friendsofsymfony/http-cache-bundle could not be found in any version, there may be a typo in the package name.
Problem 2
- Installation request for symfony/framework-standard-edition 2.5.x-dev -> satisfiable by symfony/framework-standard-edition[2.5.x-dev].
- symfony/framework-standard-edition 2.5.x-dev requires friendsofsymfony/http-cache-bundle @stable -> no matching package found.

Please help me with this issues. Thanks

support varnish management port

instead of sending special requests to the varnish frontend (and have rules that check every request for being a purge from the webserver), one could also use the telnet interface to send purge requests.

the user of the bundle should be able to call the same methods whether he uses the frontend purge controller or the one using the administration port.

http://www.varnish-cache.org/docs/3.0/reference/varnishd.html#management-interface
http://www.varnish-cache.org/docs/2.1/reference/varnishd.html#management-interface

see also TODO in https://github.com/liip/CacheControlBundle/blob/master/Helper/Varnish.php

request tagging mechanisms

why is there a difference between annotations and the configuration for creating tag headers? could these not just be 2 different ways to tell the same tools what they have to do? or is that already the case?

cache header rule configuration cleanup

currently, we have a ton of match criteria for the rules mixed up with the header configuration in case this matches.

path: ^/$
host: ^login.example.com$
methods: [ GET, HEAD ]
unless_role: ROLE_NO_CACHE
...
controls: { public: false, max_age: 0, s_maxage: 0, last_modified: "-1 hour" }
vary: [Accept-Encoding, Accept-Language]

we maybe should group this:

match:
    path: ^/$
    host: ^login.example.com$
    methods: [ GET, HEAD ]
    unless_role: ROLE_NO_CACHE
    ...
controls: { public: false, max_age: 0, s_maxage: 0, last_modified: "-1 hour" }
vary: [Accept-Encoding, Accept-Language]

possibly with the option to specify just the path outside of the match and validation in configuration that you have exactly one of match or a path specified.

see also #33

RuleMatcher for TagSubscriber, InvalidationSubscriber

we should allow to configure a global RuleMatcher in the tag_listener section instead of hardcoding the response codes (see TagSubscriber $response->isSuccessful).

i would only allow the match_response and the additional_cacheable_status options i guess, matching the request makes no sense for tags.

Merge DependencyInjection and liipDependencyInjection

and profit to clean up the configuration format. only for the existing features for now.

Symfony application functional tests

For testing the configuration and annotations, it may be useful to have tests against a Symfony application.

Rename CacheProxy to ProxyClient

As discussed in #42, the naming is a bit off. Rename in the component and the bundle. This will be a hard BC break of course. If we can merge the nginx PR first, we could do the change in one go, otherwise we break it again.

for using in the bundle, i think it makes sense to have a proxy_client.varnish and other proxy_client.X and then define the alias from the DI class for default_proxy_client. that way some really complicated setup could even run both varnish and nginx or symfony built-in cache clients, and add his own services with the other clients.

Support multiple hosts

Currently, the bundle supports only one value for host. That's a bit silly, as an application could have multiple hostnames for which caches must be invalidated.

Add user context route automatically

As discussed elsewhere, our implementation of the user context functionality requires a route to be defined. We now tell users to add that route themselves. It would be more user-friendly to do that for them, probably based on a config parameter. If we change this, we should remember to update the docs accordingly.

Cache control unless_role filter

In the request matching to decide on cache rules, there is an unless_role option that skips the rule if the user is authorized and has a specific role. This only ever makes sense when nothing is cached or responses vary on the cookie, so can only really set the max-age. @lsmith77 explained that it was built in LiipCacheControlBundle to set no cache for admin users in a project.

This option feels weird to me. To cover the use case, a match_permission would make much more sense. Then we could do a granted check if there is a security context with a token and apply that rule if its granted.

Make cache invalidation more generic

Have concrete HTTP cache implementations implement interface PurgeInterface, and, optionally, BanInterface. For instance:

• Varnish supports both
• Nginx supports purging only.

Should we copy the Varnish names (purge and ban) or stick to our own names, such as invalidateUrl and invalidateRegex or something like that?

Complete CacheManager implementation

The CacheManager, which could as a layer on top of the HTTP proxy clients, is still unfinished.

• Do we need this layer?
• What functionality should it have?
  • Decides which invalidation method (ban/purge) to use.
  • A method tagResponse that adds caching tags to responses (#2).

Send invalidation requests in parallel

This is currently possible in the Driebit bundle, but that only supports purge requests. Allowing invalidation requests to be done in parallel becomes more complex when adding ban and refresh support.

Two options:

1. A cache manager class that goes on top of our HTTP cache implementations (such as Varnish) collects all invalidation requests and then calls the corresponding methods on the Varnish class. This may be considered a clearer separation of concerns: the Varnish class shouldn't know anything about collecting requests but only about sending them. The Varnish interface becomes messier, though: purge(string[] $urls) (multiple URLs together), ban(string[] $urls) (but how to have custom headers per URL?). Maybe a custom Request that holds both URL and headers class could help here, so we get ban(Request[] $requests). Even then, it's impossible to combine all ban, purge and refresh requests together.
2. Each HTTP cache implementation (Varnish, Nginx, …) itself does the request collection. This allows for cleaner interfaces: purge($url) (single URL), ban($url, $headers, …). This does mean more duplicate code, though, between the Varnish and Nginx classes. We could have an AbstractHttpCache class that takes care of queueing and flushing, of course.

Am I missing something?