Cloudfront serves as text/plain files copied with aws s3 cp index.html s3://bucket/index.html --content-type text/html --cache-control max-age=30

[iongion]

I am facing this issue for some time now, it appears to be a delta between the copy and the actual set of content-type.

If one visits the domain associated with the bucket, in between that delta, then cloud front will server index.html as a text/plain and there would be no way to fix it without requesting cache invalidation + browser forced refresh + restart of browser.

Is there a way to ensure the proper content-type is set, prior to cloud-front accessing the object ?

[uldyssian-sh]

What you are seeing is CloudFront caching an older response (including its headers) for index.html.

aws s3 cp ... --content-type text/html does set the S3 object’s Content-Type correctly at the origin, but CloudFront caches the object (and the Content-Type header) at the edge. If an edge location already cached a previous version of /index.html that had text/plain, it can keep serving that cached header until the CloudFront TTL expires (or you invalidate), even though S3 now has text/html.

There is no “pre-warm / lock CloudFront until S3 metadata is correct” switch. The correct way to prevent this class of issue is to avoid reusing the same cache key for HTML, or force CloudFront to re-fetch on every request (or near every request).

Practical fixes:

Use cache-busting for HTML (recommended)

Deploy index.<buildid>.html and reference it (or rewrite) so CloudFront sees a new cache key:

aws s3 cp index.html s3://bucket/index.${GIT_SHA}.html --content-type text/html --cache-control "max-age=30"

Then update the entry point to reference the new object (or use a rewrite/origin function).

Or keep the name but make CloudFront stop caching it

Set CloudFront behavior/cache policy for /index.html to respect origin headers and keep TTLs minimal (e.g., Minimum TTL = 0, Default TTL = 0/very small), and ensure origin is sending Cache-Control that matches what you want.

If you must keep the same key and need immediate correctness

You must invalidate the CloudFront cache entry after upload:

aws cloudfront create-invalidation --distribution-id <DIST_ID> --paths "/index.html"

Summary:

S3 metadata can be correct immediately, but CloudFront may serve a previously cached response with the old Content-Type. To “ensure correctness before CloudFront serves it”, use a new object key (cache busting) or configure CloudFront not to cache that path (or invalidate when you overwrite).

[uldyssian-sh]

Thanks! If this helps, please consider marking it as “Helpful” or “Accepted” 😊