By using AWS re:Post, you agree to the Terms of Use
/give client browser hints from cloudFront distribution to cache assets/

give client browser hints from cloudFront distribution to cache assets

0

Hi team,

I'm configuring response headerPolicies for each of my CloudFront behaviours (for static assets)

I just want to give the client's browser a hint to cache contents for a specific time before going to the edge location.

but for one of my behaviours (only index.html)

I don't want that the client browser cache that file( index.html) at all but fetch it from the edge location instead

my response header cache policy for index.html behaviour looks like this :

{header:'cache-control', value'public, max-age=0,s-maxage=31536000, must-revalidate;', overide:tre}

but noticed each time I have a cache miss (X-cache = Error from cloud front').

not sure why I have each time a cache miss for index.html

I want to tell the client browser not to cache it but I want that the file be served from the edge location (cache HIT, NOT cache miss)

appreciate any idea how ta achieve that?

Thank you!

1 Answers
0

Hi Jess,

I believe that the response header policy is executed on the viewer response, which means this execution happens after the edge has served the object. As such, you can set a max-age value for the client, but I don't believe you can set an s-maxage in the viewer response stage. The documentation here specifically calls out setting a cache-control response header to control browser caching.

There are a few options to get around this. Note that I am assuming that you are not setting a cache-control header at the origin. I am also assuming that you have a cache behavior specifically for /index.html.

  1. In the cache policy for this specific cache behavior, set the default and max TTL's to 31536000. This should instruct the edge to cache for 31536000 seconds. In your response header policy, use your existing rule, just remove the s-maxage value. This should give you the result you are looking for, where the object is cached on the edge for desired TTL, but not cached in the browser.
  2. A second option is to use a Lambda@Edge function in the origin response stage. You are able to set both the max-age and s-maxage in the origin response stage since this stage executes before the edge serves the object. To the edge, it appears that a cache-control header is being set by the origin. Here is a sample function that you could use as a reference. Please note that in this scenario you still need to make sure that your cache policy min and max TTL values are wide enough to accommodate any cache-control values that you might be setting. For example, if you are defining a cache-control value of 300 in your Lambda@Edge function, then your cache policy max TTL must be at least 300 as well.

My personal recommendation is to use option 1, since you are defining this only for a single index.html file. If you have a requirement to define a large number of cache-control headers for different URI's, then the Lambda@Edge function is likely the better option. Just be aware that there is a cost for those function invocations.

PS, it looks like you might also have a typo in your origin override as well.

answered 20 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions