title: Cloudfront to use different Content-Type for compressed and uncompressed files
body: <p>I am serving a website generated by a static site generator via S3 and Cloudfront. The files are being uploaded to S3 with correct Content-Types. The DNS points to Cloudfront which uses the S3 bucket as its origin. Cloudfront takes care about encryption and compression. I told Cloudfront to compress objects automatically. That worked fine until I decided to change some of the used images from PNG to SVG.</p>
  
  <p>Whenever a file is requested as uncompressed it is delivered as is with the set Content-Type (image/svg+xml) and the site is rendered correctly. However, if the file is requested as compressed it is delivered with the default Content-Type (application/octet-stream) and the image is missing in the rendering. If I then right-click on the image and choose to open the image in a new tab, it will be shown correctly (without the rest of the page).</p>
  
  <p>The result is the same independent of the used browser. In Firefox I know how to set it to force requesting compressed or uncompressed pages. I also tried curl to check the headers. These are the results:</p>
  
  <pre><code>λ curl --compressed -v -o /dev/null http://dev.example.com/img/logo-6998bdf68c.svg
  * STATE: INIT =&gt; CONNECT handle 0x20049798; line 1090 (connection #-5000)
  * Added connection 0. The cache now contains 1 members
  *   Trying 52.222.157.200...
  * STATE: CONNECT =&gt; WAITCONNECT handle 0x20049798; line 1143 (connection #0)
    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                   Dload  Upload   Total   Spent    Left  Speed
    0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to dev.example.com (52.222.157.200) port 80 (#0)
  * STATE: WAITCONNECT =&gt; SENDPROTOCONNECT handle 0x20049798; line 1240 (connection #0)
  * STATE: SENDPROTOCONNECT =&gt; DO handle 0x20049798; line 1258 (connection #0)
  &gt; GET /img/logo-6998bdf68c.svg HTTP/1.1
  &gt; Host: dev.example.com
  &gt; User-Agent: curl/7.44.0
  &gt; Accept: */*
  &gt; Accept-Encoding: deflate, gzip
  &gt;
  * STATE: DO =&gt; DO_DONE handle 0x20049798; line 1337 (connection #0)
  * STATE: DO_DONE =&gt; WAITPERFORM handle 0x20049798; line 1464 (connection #0)
  * STATE: WAITPERFORM =&gt; PERFORM handle 0x20049798; line 1474 (connection #0)
  * HTTP 1.1 or later with persistent connection, pipelining supported
  &lt; HTTP/1.1 200 OK
  &lt; Content-Type: application/octet-stream
  &lt; Content-Length: 7468
  &lt; Connection: keep-alive
  &lt; Date: Wed, 01 Mar 2017 13:31:33 GMT
  &lt; x-amz-meta-cb-modifiedtime: Wed, 01 Mar 2017 13:28:26 GMT
  &lt; Last-Modified: Wed, 01 Mar 2017 13:30:24 GMT
  &lt; ETag: "6998bdf68c8812d193dd799c644abfb6"
  * Server AmazonS3 is not blacklisted
  &lt; Server: AmazonS3
  &lt; X-Cache: RefreshHit from cloudfront
  &lt; Via: 1.1 36c13eeffcddf77ad33d7874b28e6168.cloudfront.net (CloudFront)
  &lt; X-Amz-Cf-Id: jT86EeNn2vFYAU2Jagj_aDx6qQUBXFqiDhlcdfxLKrj5bCdAKBIbXQ==
  &lt;
  { [7468 bytes data]
  * STATE: PERFORM =&gt; DONE handle 0x20049798; line 1632 (connection #0)
  * Curl_done
  100  7468  100  7468    0     0  44526      0 --:--:-- --:--:-- --:--:-- 48493
  * Connection #0 to host dev.example.com left intact
  * Expire cleared
  </code></pre>
  
  <p>and for uncompressed it looks better:</p>
  
  <pre><code>λ curl -v -o /dev/null http://dev.example.com/img/logo-6998bdf68c.svg
  * STATE: INIT =&gt; CONNECT handle 0x20049798; line 1090 (connection #-5000)
  * Added connection 0. The cache now contains 1 members
  *   Trying 52.222.157.203...
  * STATE: CONNECT =&gt; WAITCONNECT handle 0x20049798; line 1143 (connection #0)
    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                   Dload  Upload   Total   Spent    Left  Speed
    0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to dev.example.com (52.222.157.203) port 80 (#0)
  * STATE: WAITCONNECT =&gt; SENDPROTOCONNECT handle 0x20049798; line 1240 (connection #0)
  * STATE: SENDPROTOCONNECT =&gt; DO handle 0x20049798; line 1258 (connection #0)
  &gt; GET /img/logo-6998bdf68c.svg HTTP/1.1
  &gt; Host: dev.example.com
  &gt; User-Agent: curl/7.44.0
  &gt; Accept: */*
  &gt;
  * STATE: DO =&gt; DO_DONE handle 0x20049798; line 1337 (connection #0)
  * STATE: DO_DONE =&gt; WAITPERFORM handle 0x20049798; line 1464 (connection #0)
  * STATE: WAITPERFORM =&gt; PERFORM handle 0x20049798; line 1474 (connection #0)
  * HTTP 1.1 or later with persistent connection, pipelining supported
  &lt; HTTP/1.1 200 OK
  &lt; Content-Type: image/svg+xml
  &lt; Content-Length: 7468
  &lt; Connection: keep-alive
  &lt; Date: Wed, 01 Mar 2017 20:56:11 GMT
  &lt; x-amz-meta-cb-modifiedtime: Wed, 01 Mar 2017 20:39:17 GMT
  &lt; Last-Modified: Wed, 01 Mar 2017 20:41:13 GMT
  &lt; ETag: "6998bdf68c8812d193dd799c644abfb6"
  * Server AmazonS3 is not blacklisted
  &lt; Server: AmazonS3
  &lt; Vary: Accept-Encoding
  &lt; X-Cache: RefreshHit from cloudfront
  &lt; Via: 1.1 ac27d939fa02703c4b28926f53f95083.cloudfront.net (CloudFront)
  &lt; X-Amz-Cf-Id: AlodMvGOKIoNb8zm5OuS7x_8TquQXzAAXg05efSMdIKgrPhwEPv4kA==
  &lt;
  { [2422 bytes data]
  * STATE: PERFORM =&gt; DONE handle 0x20049798; line 1632 (connection #0)
  * Curl_done
  100  7468  100  7468    0     0  27667      0 --:--:-- --:--:-- --:--:-- 33639
  * Connection #0 to host dev.example.com left intact
  </code></pre>
  
  <p>I don't want to switch off the compression for performance reasons. And it looks that this only happens for SVG file types. All other types have the correct, ie. the same Content-Type. I already tried to invalidate the cache and even switched it off completely by setting the cache time to 0 seconds. I cannot upload a compressed version when uploading to S3 because the upload process is automated and cannot easily be changed for a single file. </p>
  
  <p>I hope that I did something wrong because that would be easiest to be fixed. But I have no clue what could be wrong with the setting. I already used Google to find someone having a similar issue, but it looks like it's only me. Anyone, who has an idea?</p>