Caching HTTP Error Responses at Akamai
Received a request from a customer if we support Caching of HTTP Error Responses at Akamai. Of course, the behavior is available to cache HTTP Error Responses like 404s. The use case here is the following:
- Honor Origin Cache-Control settings for Error Responses for normal errors
- Set a higher TTL for HTTP Error Responses for resources that do not exist
In order to make this happen, you can follow the next steps.
- Create a new version of your delivery configuration
- Add a blank rule (e.g. Cache HTTP Error Responses) and add the Behavior Cache HTTP Error Responses. No If-criteria is needed here.
3. Add another blank rule (e.g. Broken Content) and add the IF statement "Filename is" and add the resources that are generating a high number of 404s at the origin.
4. Add the behavior Cache HTTP Error Responses and set this to a higher TTL, in this case 1 day.
5. Add the behavior Construct Response and add set the response code to 404 with any valid HTML tags.
6. Save, Push to Staging, Test and Push to Production.
NOTES: During my research I realized it is not possible to Honor Origin Cache-Control Headers for Error Responses. This is not 'stage compatible', you might come across this when you are executing logic that the EdgeServer is unable to process.
There is definitely a possibility that this is possible with an Advanced Metadata override but this is subject to implementation by Professional Services and not self-serviceable.
With the above mentioned implementation you will however be able to get rid of pesky 404-generating requests at the origin and have Akamai manage these for you.
The following blog post might be of interest as it describes how you can easily find out about the 404s that are being generated in the LUNA Monitoring: How to find out what HTTP Responses Akamai and/or your origin is serving?
If there are any questions about this, please let me know below.