Cloudflare Enabled
There is an option stored in the DB when a site has had Cloudflare Enabled by our integration. This option is named endurance_cloudflare_enabled. We previously had not filtered on this option because the purge endpoint was intended to support multiple services. Currently it only supports Cloudflare so we will filter the requests down to when this is present.
This option has not always been reliable. Sean and Team have prepared updates to make this more reliable and have also updated existing sites that are integrated to contain it.
Triggers
We pass the current trigger in the user-agent when we clear NGINX. This has proved useful in the past to help identify triggers that are causing a high qty of requests. Once identified, we can either throttle them differently or add them to our exclude lists if they have no visible impact on a site.
Since Cloudflare bundles the assets together and purges them on shutdown, we were not sending any trigger because current_action would just be the shutdown event.
This PR adds record keeping for all triggers so that they can be sent over with the bundled payload to the Cloudflare endpoint. This enables us to troubleshoot and become more efficient in the future. This has no functional effect on when purges happen.
Type of Change
[x] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices apply)
Further comments
It is additionally worth noting that this branch was created off of cloudflare-optimizations which has now been merged and deployed.
We should not deploy this until we hear confirmation from Sean Cox or Ron Fulmer that the code changes that have been prepared to make the endurance_cloudflare_enabled more reliable have rolled. Rolling this first could put us in the opposite and worse scenario where a site needs to purge and does not.
Proposed changes
Cloudflare Enabled There is an option stored in the DB when a site has had Cloudflare Enabled by our integration. This option is named
endurance_cloudflare_enabled. We previously had not filtered on this option because the purge endpoint was intended to support multiple services. Currently it only supports Cloudflare so we will filter the requests down to when this is present.This option has not always been reliable. Sean and Team have prepared updates to make this more reliable and have also updated existing sites that are integrated to contain it.
Triggers We pass the current trigger in the user-agent when we clear NGINX. This has proved useful in the past to help identify triggers that are causing a high qty of requests. Once identified, we can either throttle them differently or add them to our exclude lists if they have no visible impact on a site.
Since Cloudflare bundles the assets together and purges them on shutdown, we were not sending any trigger because current_action would just be the shutdown event.
This PR adds record keeping for all triggers so that they can be sent over with the bundled payload to the Cloudflare endpoint. This enables us to troubleshoot and become more efficient in the future. This has no functional effect on when purges happen.
Type of Change
Further comments
It is additionally worth noting that this branch was created off of cloudflare-optimizations which has now been merged and deployed.
We should not deploy this until we hear confirmation from Sean Cox or Ron Fulmer that the code changes that have been prepared to make the
endurance_cloudflare_enabledmore reliable have rolled. Rolling this first could put us in the opposite and worse scenario where a site needs to purge and does not.