SVG files with wrong content type in CloudFront

Question

We have a website that contains some .svg files. It it stored as a static site in an S3 bucket with CloudFront. When we initially uploaded the files to the bucket all the .svg files got the wrong Content-Type property, they got binary/octet-stream rather than image/svg+xml. I've seen that various people have had this issue. Whatever the reason, we converted them back to image/svg+xml but they are still being downloaded by the browser as binary/octet-stream.

Couple of notes:

• When we point the browser at the default s3 bucket website (http://my-kule-site.s3-website-us-east-1.amazonaws.com) then all the svg files come down with the correct content type. It's only when we hit the site through CloudFront that we have the issue.

• When I curl the svg file without specifying any headers it comes back with the correct Content-Type.

$ curl -i https://my-kule-site.com/img/whatup.svg
HTTP/2 200 
content-type: image/svg+xml
content-length: 3342
date: Tue, 13 Aug 2019 16:48:48 GMT
last-modified: Mon, 12 Aug 2019 14:39:35 GMT
x-amz-version-id: ZJRubnV_5a0U53bM1JHqLgdkklu.dsLA
etag: "1870f06100c651976bd353d0b620a810"
server: AmazonS3
x-cache: Miss from cloudfront
via: 1.1 64b0aa0bda8aeed651e25c63b33d01cb.cloudfront.net (CloudFront)
x-amz-cf-pop: DFW53-C1
x-amz-cf-id: UYKuqWq1DbSGzlhsWN08cCaFJi7-ZzhNIjNiIOR5Wqp4xJq4enWMCQ==

However, when I use Chrome to convert the request to a curl I get the wrong Content-Type:

curl -i 'https://my-kule-site.com/img/whatup.svg' \
-H 'pragma: no-cache' \
-H 'cookie: _ga=GA1.2.1895535225.1553806453; rxVisitor=1565278857790QSUIL3RKP345UQV1JFIPAGLOUE0QTANP; _gid=GA1.2.2146389308.1565619566' \
-H 'accept-encoding: gzip, deflate, br' \
-H 'accept-language: en-US,en;q=0.9,it;q=0.8,fr;q=0.7' \
-H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36' \
-H 'sec-fetch-mode: no-cors' \
-H 'accept: image/webp,image/apng,image/*,*/*;q=0.8' \
-H 'cache-control: no-cache' \
-H 'authority: my-kule-site.com' \
-H 'referer: https://my-kule-site.com/' \
-H 'sec-fetch-site: same-origin' --compressed

HTTP/2 200 
content-type: binary/octet-stream
content-length: 3342
date: Mon, 12 Aug 2019 14:19:31 GMT
last-modified: Tue, 06 Aug 2019 22:06:08 GMT
x-amz-version-id: 2yDH.ceFE2OMxBKqZ0hf1uJYIM0cz_0g
etag: "1870f06100c651976bd353d0b620a810"
server: AmazonS3
age: 3959
x-cache: Hit from cloudfront
via: 1.1 5bf69ea12932bf924b52d57ed5314c14.cloudfront.net (CloudFront)
x-amz-cf-pop: DFW53-C1
x-amz-cf-id: UOLzk1L_jwKnLM4YTwowHKUxSHYlpAOq9rGyr89xEYDhMhuBndT8Sg==

If I remove the gzip from accept-encoding like this:

-H 'accept-encoding:, deflate, br'

then it comes back with Content-Type: image/svg+xml.

Does anyone know what's going on here? Doesn't seem like a CloudFront caching thing. Why would the gzip header affect it like this and is there anyway to fix this?

Answer 1

Note the different values for last-modified and x-amz-version-id on the two responses.

CloudFront caches multiple copies of objects in some cases, so that can serve the correct one based on the request it received. It ignores many request headers that shouldn't cause the response to vary, but in this case, you're seeing a variation based on accept-encoding.

You need to do a CloudFront cache invalidation for this object or perhaps the whole distribution (/*) if there are other similar objects. Once that invalidation is complete, this should no longer be a problem.

Note also that CloudFront ignores pragma and cache-control in the request. It only honors cache-control in the response from the origin, not from the browser.