We are testing a multi-CDN setup : Client —> Akamai –> Fastly —> Origin
The traffic itself works fine . The problem is with purge API. With above setup, purge API fails. However, it succeeds when we replace Akamai with Fastly directly. That tells me that a CNAME check is done for API. 2 questions : a. Is my understanding correct ? b. if yes, how to make the api work with the multi-CDN setup
I’m assuming from what you describe that you are sending an HTTP request to the URL using a PURGE method. Please correct me if I am incorrect and we can proceed from there.
If I am correct, your purge request will land with Akamai and I expect be blocked there as an invalid request. You could configure Akamai to forward requests with a PURGE method on to the origin which should solve the purging in the Fastly tier.
In this architecture you will want to make sure you purge / update content in careful order starting with the origin and moving each layer out to the client to ensure each cache retrieves the new content and not stale content from a cache behind it. In your diagram you’d want to purge in this order:
Another solution to what you described would be to send the purge directly to Fastly. Depending on your configuration you will want to make sure the values used in the cached content and the purge request match to ensure purging works.
Let us know how you get on and if we can guide further.
No. The apis are always directed to api.fastly.com, correct?
Let me explain more:
The hostname in interest is dam.zeiss.com . It is currently pointed to Fastly directly. Everything works fine.
The moment we change the CNAME of it to Akamai and then to Fastly ( i.e., Client –> Akamai –> Fastly ) , purge api fails. What might be going wrong ? I
Please explain what you mean by ‘fails’. Do you receive an error response, or do you receive a success response but the content is not purged? How are you testing whether the content has been purged or not?
Fails —> 400 bad request
For the purge using api.fastly.com m ethod, when can we get 400 response ? on what scenarios
Unfortunately our API documentation does not specify which sorts of input might generate a ‘400’ response - ‘400’ is typically used for any type of input which does not meet the requirements of the API operation.
It would be quite surprising if a direct API call to api.fastly.com worked when the traffic landed directly on Fastly and did not work when the traffic went through Akamai on the way to Fastly - the Purging API has no way to know that the regular traffic would follow one path or the other.
Since you’ve seen failures with a specific API endpoint on a specific service, it would be best to move this to a support ticket so that you can provide a SID, an example API request/response, and other details which would not be suitable for a public forum.
Thank you @kevin.fleming . Do you happen to know what purge method does Aprimo SaaS uses ? Cos my question is directly related to the Aprimo SaaS which uses Fastly.
I don’t, but even if I happened to know we would not be able to disclose the operational details of how a Fastly customer uses the platform 