Caching headers on Amplify served content

This header on every response also seems potentially problematic?

x-cache: Miss from cloudfront

I'm seeing the same issue. Currently, I'm testing setting the "cache" option in my Amplify Console -> Build Settings to point to the src/static/media/* path. Will report back if that works!

Edit: nope, that didn't do it.

More info:
Using a CRA-based app, with Amplify CLI. No hosting set up through the CLI though -- strictly just managing hosting via the Amplify Console.

I thought I was so close with the Build Settings step...

Hope someone can clarify how CloudFront is set up for Amplify Console apps.

Edited by: warren-dev on Jul 16, 2019 10:26 AM

Final edit:

I get it! The Cloudfront setting is a feature, not a bug :) I was registering my service-worker.js incorrectly. Now that the service-worker.js is registered, it caches my assets just fine -- disregarding the CloudFront cache-control commands for those assets. Easy!

Edited by: warren-dev on Jul 16, 2019 1:51 PM

Unfortunately, I'm not using the framework, just hooking my Jekyll repo directly up in the console so the setup is even more opaque to me.

We have a blog that explain the cache invalidation for our service. https://aws.amazon.com/blogs/mobile/aws-amplify-console-supports-instant-cache-invalidation-and-delta-deployments/

So the 0 ttl cache headers are on purpose, forcing the browser to always redownload every resource? That seems like it would be fine for smaller content, but given the fact that I have a lot of large images, it just makes every page load extremely heavy since none of them are ever cached locally. Chrome seems to handle this fine since it's sort of ignoring the cache headers anyway, but Safari/Mobile Safari are following the rules exactly and every page load takes a long time to fill in the image content.

Is there a way to change the cache invalidation settings, to say leave this as-is for most content but allow browser caching on specific paths (/assets/images/big_content/**)? Understanding that there may be some lag time between the deploy and ttl expiration for that particular content, I would take that over not allowing any browser caching at all.

For other's whom may need this in the future, the Amplify Console Customer Headers feature can be used to set headers, in order to let browser cache specific paths.
https://docs.aws.amazon.com/amplify/latest/userguide/custom-headers.html

I went ahead and added these customHeaders to build settings file in my project (from the Amplify Console > App settings > Build Settings. (NOTE: my project is set up to add content hashes to all of these static assets, so caching them permantently is what I want.)

frontend:
  phases: …
  artifacts: …
  customHeaders:
    # cache static assets!
    # js
    - pattern: '**/*.js'
      headers: [ { key: 'Cache-Control', value: 'public,max-age=31536000,immutable' } ]
    # css
    - pattern: '**/*.css'
      headers: [ { key: 'Cache-Control', value: 'public,max-age=31536000,immutable' } ]
    # images
    - pattern: '**/*.gif'
      headers: [ { key: 'Cache-Control', value: 'public,max-age=31536000,immutable' } ]
    - pattern: '**/*.jpg'
      headers: [ { key: 'Cache-Control', value: 'public,max-age=31536000,immutable' } ]
    - pattern: '**/*.png'
      headers: [ { key: 'Cache-Control', value: 'public,max-age=31536000,immutable' } ]
    - pattern: '**/*.svg'
      headers: [ { key: 'Cache-Control', value: 'public,max-age=31536000,immutable' } ]
    # videos
    - pattern: '**/*.mp4'
      headers: [ { key: 'Cache-Control', value: 'public,max-age=31536000,immutable' } ]
    - pattern: '**/*.webm'
      headers: [ { key: 'Cache-Control', value: 'public,max-age=31536000,immutable' } ]

Questions:

1. Is there a simpler way to have the pattern match—is this standard glob syntax? Can I just do: ''**/*.{js,css,gif,jpg,png,svg,mp4,webm}''
2. Is there something I can do to also get my HTML pages to 304? I’m seeing both etag and if-modified-since request headers matching the response headers, but every time there’s the response headers server: AmazonS3; status: 200; x-cache: Miss from cloudfront