customHttp.yml Cache-Control directive not applied anymore

[marcolucio]

Before opening, please confirm:

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

App Id

d33tomgegl6zji

Region

eu-central-1

Amplify Console feature

Custom headers

Describe the bug

Hello, We found that our custom Cache-Control headers are no more applied resulting in Cache-Control: public, max-age=0, s-maxage=2 for all files. This is very critical for our app performance. Other headers seems to be applied correctly, or at least the one with '*/' pattern is applied to all files properly.

Our customHttp.yml is structured like:

  - pattern: '**/*.html'
    headers:
      - key: Cache-Control
        value: 'public, max-age=0, s-maxage=120, must-revalidate'

  - pattern: '**/*'
    headers:
      - key: X-Version
        value: '_VERSION_'

If I ask by wget / curl for a single html file our custom X-Version header is correctly served, but not the Cache-Control one. It worked properly until last week.

Expected behavior

Cache-Control headers (or others) should be properly applied by pattern matching.

Reproduction steps

1. Create a project with a customHttp.yml containing:

   - pattern: '**/*.html'
   headers:
     - key: Cache-Control
       value: 'public, max-age=0, s-maxage=120, must-revalidate'
   
   - pattern: '**/*'
   headers:
     - key: X-Version
       value: '_VERSION_'

   and a simple test.html file

2. Deploy it using amplify console
3. Ask for http:///prova.html, the response should contain custom X-Version: _VERSION_ + Cache-Control: public, max-age=0, s-maxage=120, must-revalidate headers

Build Settings

No response

Additional information

No response

[github-actions[bot]]

Hi :wave:, 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!

[biller-aivy]

Same for

customHeaders:
  - pattern: '**/*'
    headers:
      - key: Access-Control-Allow-Origin
        value: '*'

I guess this is not a CLI Problem. More a Amplify Console Problem? when I add the customHeaders over the Console it is also not working.

[iceye]

here I'm experiencing the same issue

[ghost]

Hi @marcolucio 👋🏽, thanks for raising this issue. I was not able to reproduce this behavior with the '**/*.html' pattern. We are currently investigating this.

[marcolucio]

Thank you @hloriana. Let me know asap, we are heavily relying on caching so this issue is really critical for us. If it could help: our traffic pattern on CDN changed the 21th of January. Any temporary workaround while waiting for fix is welcome.

[ghost]

@marcolucio I was able to get this to work; have you tried to re-deploy your app to make sure the headers are being picked up?

[marcolucio]

@hloriana our last deploy ended at 6.20 CET.

I performed some tests and the **/*.html seems to work properly now (it reports Cache-Control: public, max-age=0, s-maxage=120, must-revalidate)

Hovever other paths are still reporting the wrong Cache-Control: public, max-age=0, s-maxage=2.

If you have a look at our customHttp.yml we have also a bunch of paths like:

  - pattern: /version.txt
    headers:
      - key: Cache-Control
        value: 'public, max-age=0, s-maxage=300, must-revalidate'

  - pattern: /client/**/*
    headers:
      - key: Cache-Control
        value: 'public, max-age=7200, s-maxage=14400, must-revalidate'

They are all reporting the wrong Cache-Control. Let me know if I have to perform more tests or deploys, thank you.

[ryomtoob]

I am also experiencing the problem with the Access-Control-Allow-Origin header. We didn't make any changes, and it stopped serving the header sometime over last weekend.

[ghost]

@biller-aivy @iceye @ryomtoob can you share your App ID and the region they're deployed in?

[biller-aivy]

@biller-aivy @iceye @ryomtoob can you share your App ID and the region they're deployed in?

d1fc4aexqs2mpi

eu-central-1

[ryomtoob]

dx4a6kvkkrewc us-east-1

[marcolucio]

@hloriana, If it cloud help the problem for us is starting on 26th of Jan at 6.00 AM CET, immediately after the first deploy of the day, thank you

[iceye]

@biller-aivy the appid/region is in the first comment from @marcolucio, I try to create a new app with the same code and the issue is still there.

[biller-aivy]

reDeplyod the Production Branch and now it is working again.

[ryomtoob]

I am still having the issue. I tried redeploying, but the header still isn't showing up.

[iceye]

Our app App Id d33tomgegl6zji - Region eu-central-1 (is the first comment one from @marcolucio ) too, it's flushing every ~1h but no changes yet

Enabling performance mode soled some big issue but with others side effects on client side

[ghost]

@marcolucio can you please try this pattern:

- pattern: version.txt
    headers:
      - key: Cache-Control
        value: 'public, max-age=0, s-maxage=300, must-revalidate'

  - pattern: client/**/*
    headers:
      - key: Cache-Control
        value: 'public, max-age=7200, s-maxage=14400, must-revalidate'

If you make this change in the customHttp.yml file please make sure you re-deploy.

[ghost]

@iceye and @ryomtoob can you modify your pattern by removing the leading slash and see if this resolves the issue? For example, try file.txt instead of /file.txt.

[marcolucio]

@hloriana we changed our customHttp.yml removing all leading / from paths and it works properly. Is it correct to assume that all paths must not start by / or do you plan to fix the behaviour?

Thank you for your support.

[ryomtoob]

@hloriana removing the leading slash and redeploying resolved the issue thank you.

[iceye]

@hloriana I confirm too

[ryomtoob]

I am running into this problem again with a different project with App Id d20my976ongmfk in region us-east-1. The project didn't have any custom headers configured, so I added the Access-Control-Allow-Origin header via the customHttp.yml editor in the console. I have redeployed my PR preview several times, but the header is not being served. I ensured that my path doesn't have a leading slash as that was the resolution previously. I also attempted the Cache-Control workaround provided in this issue aws-amplify/amplify-hosting#1563, but no luck with that either. @hloriana could you please provide some guidance for the problem?

[ryomtoob]

@hloriana I am still having the problem in the above comment. Could you please advise?

[saadataz]

Closing this issue as the original issue has been resolved.

@ryomtoob can you please open another issue if you are still seeing the problem.

[github-actions[bot]]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.

[github-actions[bot]]

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.