[WIP][RFC] Fastly support

[hpatoio]

Adding support for Fastly
Goes with FriendsOfSymfony/FOSHttpCacheBundle#427

For details about Fastly API:

• https://docs.fastly.com/api/purge#soft_purge_2e4d29085640127739f8467f27a5b549
• https://docs.fastly.com/api/purge#purge_d8b8e8be84c350dd92492453a3df3230

Related discussion: #142

[dbu]

thanks for starting this! i am super busy before php benelux, will try to have a look at this next week.

do you have specific questions at this point? what remains to be done (apart from test and style issues)?

[hpatoio]

do you have specific questions at this point?

No, not really

what remains to be done (apart from test and style issues)?

The FastlyProxyClient need implements:

• TagCapable
• PurgeCapable
• RefreshCapable

And then documentation.

[dbu]

cool. then i will ignore that pull request for now, please ping me when you need input or want me to review something. i would love to have fastly support in this library!

[andrerom]

In the case of hard purge, it's possible to invalidate 256 tags at a time now:
https://docs.fastly.com/api/purge#purge_db35b293f8a724717fcf25628d713583

[andrerom]

Seems they are also able to do this on Soft purge, via support there they seem to plan to update doc to make it more clear.

So given Fastly has API rate limits, we should change to use the API linked to above regardless of soft/purge so we can purge up to 256 tags at a time severely reducing risk of hitting API limits.

[andrerom]

I think we might have another todo here. From what I could see last week, UserContextInvalidator also needs to be changed to not rely on BanCable for this to be possible.

One alternative would be to add tags for user id and session id on the hash request cache. Any thoughts on this @dbu ?

[dbu]

so it would be possible to do user context caching with fastly, if we find a way around the ban issue? that would be quite cool indeed.

how do we do that with the symfony cache kernel thingy? that one does not have full banning implemented, but does have tags. do we not invalidate the hash lookup for that case?

[dbu]

tagging the hash lookup response with the session id would be a very good idea imho. with the xkey extension, invalidating the tag would also be much better for varnish than the ban request that we currently do. (apart from that ban request being completely broken and banning the whole server each time)

[andrerom]

how do we do that with the symfony cache kernel thingy? that one does not have full banning implemented, but does have tags. do we not invalidate the hash lookup for that case?

Unsure how it is done here, maybe @Toflar remember?

[Toflar]

The Symfony Proxy is not BanCapable but I'm not sure what the question here is?

[andrerom]

The Symfony Proxy is not BanCapable but I'm not sure what the question here is?

Q: How Use Context hash invalidation is done with Symfony Proxy, given UserContextInvalidator in bundle expects BanCapable, which Symfony Proxy does not implement.

At least I got issue with that when trying to do Fastly POC using cache_manager.custom_proxy_client.

---

@dbu While on that, I also ran into another possible thing we should think about for full Fastly support. And that is find a way to map FOS's reverse_proxy_ttl header to Fastly's Surrogate-Control header: https://docs.fastly.com/guides/performance-tuning/controlling-caching#changing-caching-times-for-different-users

[Toflar]

I'm not using the User Context at all, I'm using our https://github.com/terminal42/header-replay-bundle. So I think this probably doesn't work?

[dbu]

user context

i found it: https://github.com/FriendsOfSymfony/FOSHttpCacheBundle/blob/98280a84704952c9730128e29844f9b9fe6ea3e8/src/DependencyInjection/Configuration.php#L117-L140

we indeed require a ban capable client. in the default auto setting, we enable the logout handler for varnish, noop and when a custom proxy client is configured.
if we would change the hash lookup response to be tagged with the session id, we could use tag invalidation which works at least as well with varnish (with xkey its an improvement) and it would then also work with the symfony cachekernel.

so in short, i think we should do that (better in a separate pull request). given that user context logout handling never worked properly even for varnish, i think we can do this in a minor version and do not need a major version.

reverse_proxy_ttl

the X-Reverse-Proxy-TTL header is currently hardcoded in CacheControlListener: https://github.com/FriendsOfSymfony/FOSHttpCacheBundle/blob/98280a84704952c9730128e29844f9b9fe6ea3e8/src/EventListener/CacheControlListener.php#L136

we should introduce a configuration to switches to the surrogate control mode and do the switch automatically if the fastly client is the default client. for the next major version, i think we should switch all proxies to use the surrogate-control header for this information, as that standard seems to cover this. thats better than using a custom header. but thats a BC break, so supporting both modes for now and deprecating the old mode would be the best upgrade path.

[andrerom]

+100

[dbu]

meanwhile we use cache tagging for the context hash response in master.

do you plan to work on any of the subjects we discussed here @andrerom to wrap up fastly support?

[andrerom]

do you plan to work on any of the subjects we discussed here @andrerom to wrap up fastly support?

I haven't planned for that, what I did for demo at symfony live can be found here. It's not tested against Fastly funtionally, but it has support for purging several tags at once when doing hard purging which can also be added here, but besides that it's very similar to the code here.

[dbu]

continued in #451