Related

Error 1001 DNS resolution error Question Question
Frequent Error 522 on App Question Question

Question

Cloudflare cache invalidation on App Platform

Posted December 22, 2020 675 views
CDNDigitalOcean App Platform

Are cache tags supported (and their invalidation) with App Platform and the Cloudflare CDN? I’d like to make sure my requests have proper Cache-Tag headers. The problem is that invalidation with Cloudflare is an API based process.

If the Cache-Tags header isn’t available, what is a good way to handle cached responses on App Platform without setting a low Cache-Control header.

Add a comment
nmd.matt
By:
nmd.matt

Related

Error 1001 DNS resolution error Question Question
Frequent Error 522 on App Question Question

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
1 answer
kamaln7 December 22, 2020

👋🏼 @nmd.matt

App Platform doesn’t support Cache-Tag headers at this time, however, you can make use of Cache-Control headers per Cloudflare’s guidelines: https://support.cloudflare.com/hc/en-us/articles/115003206852-Understanding-Origin-Cache-Control

For Static Site components, we set a Cache-Control header automatically and explicitly purge the CDN cache on each app deployment. I hope that helps!

Reply Report
  • madkins December 23, 2020

    @kamaln7 For Static Site components, can we configure the Cache-Control header? This would be a super useful feature if it isn’t currently supported.

    Reply Report
  • devservicesLobster December 30, 2020

    I’m deploying a create-react-app, but it seems like the CDN cache is not being purged with each deployment. I see several things lingering, and updates to the code not reflected on the site.

    For example, I’m using client-side routing. So, before I set the catchall page it would 404 on a browser refresh. Now, I’ve set the catchall page, but there is still one (and only one) route that shows a 404 - it’s the same route that I first discovered. For some reason this seems to be “stuck” even after deploying several times.

    I see that the cache-control response header is: public,max-age=10,s-maxage=86400, so I will wait 24 hours and see if the cloudflare cache does invalidate. Is that just simply what needs to be done - wait 24 hours for every new deployment to actually show for regular users? I’d like for new features to show a bit quicker.

    Reply Report
    • devservicesLobster January 4, 2021

      I can confirm that the cache does clear after 24 hours. Is there a way to force the cache to clear when a new version is deployed?

      Reply Report
      • kamaln7 January 6, 2021

        With public,max-age=10,s-maxage=86400, browsers are instructed to cache files for 10 seconds and proxies/caches for 86400 seconds/24 hours. Cloudflare will respect the 24 hour setting, but we call the Cloudflare API to purge the cache on new deployments so that Cloudflare can pick up the changes instantly.

        Is it possible that there’s another proxy in between your browser and Cloudflare that’s picking up the 24 hour cache interval? Either way, I’m logging an internal ticket for this so we can look into further.

        Allowing more control over the Cache-Control header is on the roadmap but for now this header is set on all static sites.

        Now, I’ve set the catchall page, but there is still one (and only one) route that shows a 404 - it’s the same route that I first discovered. For some reason this seems to be “stuck” even after deploying several times.

        Was this fixed after 24 hours?

        Reply Report
        • devservicesLobster January 7, 2021

          Thanks for the reply, @kamaln7. Yes, the issue did resolve after 24 hours so I’m certain it was indeed cache-related.

          I’ve published several more times and what I notice is that sometimes this will cause the cache to miss, and other times it will not. There is no other cache in-between, and I can see in the browser dev tools that the responding web server is Cloudflare. I have not really noticed any particular pattern to this, but it does seem to clear the cache more often than not. Perhaps there are some specific deployment criteria that trigger the Cloudflare API request to purge the cache?

          I just did a bit of testing and captured what I see before and after a static site deployment. I made code changes to this specific page that I’m refreshing.

          Prior to deployment
          Age: 316
          cache-control: public,max-age=10,s-maxage=86400
          Date: Thu, 07 Jan 2021 02:24:40 GMT
          last-modified: Wed, 06 Jan 2021 04:35:10 GMT
          Server: cloudflare

          Refresh immediately after deployment
          Age: 1403
          cache-control: public,max-age=10,s-maxage=86400
          Date: Thu, 07 Jan 2021 02:42:47 GMT
          last-modified: Wed, 06 Jan 2021 04:35:10 GMT
          Server: cloudflare

          Refresh a full 5 minutes after the deployment
          Age: 1704
          cache-control: public,max-age=10,s-maxage=86400
          Date: Thu, 07 Jan 2021 02:47:48 GMT
          last-modified: Wed, 06 Jan 2021 04:35:10 GMT
          Server: cloudflare

          Reply Report
          • kamaln7 January 8, 2021

            Thanks @devservicesLobster, that’s helpful. I appreciate the additional testing.

            I may have a lead on what the issue could be. I see that you have a wildcard domain, are you seeing this issue on the wildcard subdomains? What about the domain itself? And the default .ondigitalocean.app domain?

            Thanks!

            Reply Report
    • devservicesLobster January 9, 2021

      @kamaln7, the forum will not let me reply to comments nested any deeper, so I’m backing it back out to my original post.

      It looks like you’re on to something! The domain itself does indeed clear the cache immediately after a deployment. It’s the subdomains that do not. In my specific case, this is a multi-tenant application and I use the subdomain to segregate the tenants from one another.

      Reply Report
      • kamaln7 January 14, 2021

        @devservicesLobster sorry for the delay and thanks for following up. I can confirm that the issue is indeed with wildcard domains. We have started working on a fix but in the mean time I would recommend adding each of the subdomains to your app if possible to ensure that the cache is cleared on deploy.

        Reply Report
        • berndzelba January 16, 2021

          We do have the exact same issue with our SPA, adding each subdomain would be no option for us. Can you give a rough estimate when it will be resolved (and how do we know if it will be resolved :D)?

          Have a nice day!

          Reply Report
        • devservicesLobster January 17, 2021

          Thanks @kamaln7, in my case, for the dev/test sites adding some of the subdomains directly should work just fine until a fix is available - thanks for the suggestion! Thanks again for getting this into the backlog.

          Reply Report
Submit an Answer

Related

Looking for something else?

Ask a new question Search for more help