Describe the bug
JSON data files for SSG pages (e.g. `_next/data/{build id}/file.json) are not being cached by Cloudfront, meaning that subsequent calls always go to the origin (and trigger the Lambdas@Edge).
To Reproduce
x-cache response header set to Miss from cloudfrontExpected behavior
On step 3 above, we should observe Hit from cloudfront
Additional context
During the upload of these files, no Cache Control is set, which I suspect is the underlying cause. There should be no concern about caching these for a long time, since the build ID is in the path and SSG data should not vary within a single build.
Nice find. This would be a good case to cover for e2e tests I'm working on, we can inspect the x-cache header after hitting it a second time to ensure it says Hit from cloudfront
Looks like the cache-control header needs to be set, but also the CloudFront behavior for _next/data/* has a default, min and max TTL of 0, so cache-control header alone won't help.
We will need to fix the aws-cloudfront component to set these three values independently. In fact, it's also affecting the other CloudFront behaviors, e.g for static files, default/min/max TTL is always 86400, so even for static files they'll get evicted from the CloudFront edge cache after 1 day, even though we are setting Cache-Control for those in S3 for much longer (e.g 1 year for static JS files, 31 days for static pages).
Will work on a PR to fix it this week.
Most helpful comment
Nice find. This would be a good case to cover for e2e tests I'm working on, we can inspect the
x-cacheheader after hitting it a second time to ensure it saysHit from cloudfront