Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom HTTP Pattern Not Matching Multiple Font Extensions in Amplify #3937

Closed
3 tasks done
Petri-Oosthuizen opened this issue Jun 5, 2024 · 4 comments
Closed
3 tasks done
Labels
archived This issue has been locked. feature-request New feature or request

Comments

@Petri-Oosthuizen
Copy link

Petri-Oosthuizen commented Jun 5, 2024

Before opening, please confirm:

Amplify Hosting feature

Custom headers

Is your feature request related to a problem? Please describe:

Custom HTTP Pattern Not Matching Multiple Font Extensions in Amplify

Describe how you'd like this feature to work

Description:

I'm encountering an issue with custom headers in AWS Amplify when configuring them for multiple font file extensions using a pattern in the customHttp.yml file. While setting direct headers for individual extensions works, using a pattern with curly braces ({}) to match multiple extensions (e.g., **/*.{woff,woff2,ttf,otf,eot}) doesn't seem to apply the headers as expected.

Expected Behavior:

The custom header configuration should match files with any of the specified font extensions (woff, woff2, ttf, otf, eot) within the project directory structure and apply the defined headers (e.g., Cache-Control).

Actual Behavior:

The custom header is only applied to files with the exact extension listed first in the pattern (e.g., only .woff files in this case).

Steps to Reproduce:

  1. Create a new Amplify project or use an existing one.
  2. Add a customHttp.yml file to the project root directory.
  3. Include a pattern like this in the customHttp.yml file, replacing the value with your desired caching settings:
customHeaders:
  - pattern: "**/*.{woff,woff2,ttf,otf,eot}"
    headers:
      - key: Cache-Control
        value: max-age=86400, public  # Example caching for fonts
  1. Deploy the Amplify application.
  2. Verify by inspecting network requests in browser developer tools. The custom headers might not be applied to font files with extensions other than the first listed one (e.g., .woff2, .ttf, .otf, or .eot).
  3. Change headers to:
customHeaders:
  - pattern: "**/*.woff2"
    headers:
      - key: Cache-Control
        value: max-age=86400, public  # Example caching for fonts
  1. Deploy the Amplify application.
  2. Verify by inspecting network requests in browser developer tools. The custom headers will be applied to woff2 fonts.

Summary:

  • I've tried using a character class ([woff|woff2|ttf|otf|eot]) within the braces, but the behavior seems to be the same.
  • Setting direct headers for individual font extensions (e.g., **/*.woff, **/*.woff2) works as expected.

Questions:

  • Is there a known limitation with using patterns for multiple font file extensions in Amplify custom headers?
  • If so, are there any recommended workarounds or alternative approaches to achieve the desired behavior?
  • Could there be a configuration issue in my customHttp.yml file?

Thank you for your assistance!

@Petri-Oosthuizen Petri-Oosthuizen added the feature-request New feature or request label Jun 5, 2024
Copy link

github-actions bot commented Jun 5, 2024

This has been identified as a feature request. If this feature is important to you, we strongly encourage you to give a 👍 reaction on the request. This helps us prioritize new features most important to you. Thank you!

@calavera
Copy link
Contributor

Thanks for opening this issue. Pattern ranges like the one in your example are supported now.

Copy link

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.

Copy link

This issue has been automatically locked.

@github-actions github-actions bot added the archived This issue has been locked. label Jun 25, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Jun 25, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
archived This issue has been locked. feature-request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants