Hi @jamiepittock both of those options will give you the same end result, it just depends on where you would prefer to maintain the controlling logic.
If you have full access to your code base, and making header changes doesn’t involve a great deal of maintenance work or restrictions, setting
Surrogate-Control rules as needed on your origin may be best. You can keep the logic in version control, and the rules will be visibly apparent in your regular development process.
If you don’t have access to the full code base of your application, or if there’s a great deal of uphill effort to get code changes deployed in your organization, setting up the caching rules within Fastly may make more sense. Then you can send
Cache-Control headers to your end users via the CDN to enforce no caching.
It ultimately comes down to your call as to where the rules should reside.