Requests cached even with Cache-Control: private

[asabourin]

Before opening, please confirm:

• I have checked to see if my question is addressed in the FAQ.
• I have searched for duplicate or closed issues.
• I have read the guide for submitting bug reports.
• I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

App Id

d1ysqm6gle2xq

Region

ap-southeast-2

Amplify Console feature

Redirects

Describe the bug

We have set up a rewrite rule as per https://github.com/aws-amplify/amplify-console/blob/main/FAQ.md#reverse-proxying-to-external-api to avoid CORS preflight requests when our SPA sends requests to our API hosted on another domain.

However even though the API responses include Cache-control: private headers, we're still seeing requests returned from the CDN cache with the x-cache: Hit from cloudfront header when they are fired quickly within a 1-2sec period.

Looking at the bottom of the Specifying the amount of time that CloudFront caches objects section of https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html we suspect this is happening because there's a minimum TTL set up on the distribution, which seems confirmed by this comment.

This is causing issues for our users when they perform some actions quickly in our app and are not seeing data updated accordingly.

Short of adding a "cacheBuster" param or header to all our requests, is there a way to ensure request to paths under the rewrite rule are only ever cached by the CDN if allowed by Cache-control?

Thanks for your help!

Expected behavior

Given a rewrite rule like

[
  {
    "source": "/foo/<*>",
    "target": "https://some.other.domain/resource/<*>",
    "status": "200",
    "condition": null
  }
]

we expect all requests to /foo/* (with or without etags header) to be cached or not by the CDN according to the Cache-control header returned by https://some.other.domain/resource/*

Reproduction steps

while :; do curl -i -s -o /dev/null -D - https://app.com/foo/bar | grep x-cache; sleep 0.5; done
x-cache: Miss from cloudfront
x-cache: Hit from cloudfront
x-cache: Hit from cloudfront
x-cache: Hit from cloudfront
x-cache: Miss from cloudfront
x-cache: Hit from cloudfront
x-cache: Hit from cloudfront
x-cache: Hit from cloudfront
x-cache: Miss from cloudfront

Build Settings

No response

Additional information

No response

[github-actions]

Hi 👋, thanks for opening! While we look into this...

If this issue is related to custom domains, be sure to check the custom domains troubleshooting guide to see if that helps. Also, there is a more general troubleshooting FAQ that may be helpful for other questions.

Lastly, please make sure you've specified the App ID and Region in the issue!

[ferdingler]

Hi @asabourin,

Your observation is correct. We have a minimum TTL defined on our distributions that forces responses to be cached for at least 2 seconds. However, we also cache based on the Authorization header which prevents your end users from getting mixed responses. For example, User A will not get a cached response from User B. Assuming that you use the Authorization header with a bearer token to uniquely identify users.

[asabourin]

Thanks for confirming @ferdingler, so is there no way to configure the minimum TTL to be 0?

This is a blocker for us because we have some speed sensitive workflows where a user triggers a refresh of some data within 2s of that data being loaded initially. The same data is fetched from the cache which results in confusion as the user doesn't see the effect of their action.

[ghost]

Hi @asabourin can you confirm if you're still running into this issue?

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.