Cloudfront, um verschiedene Content-Typen für komprimierte und unkomprimierte Dateien zu verwenden

Question

Ich verwende eine Website, die von einem statischen Site-Generator über S3 und Cloudfront generiert wird. Die Dateien werden mit den richtigen Inhaltstypen nach S3 hochgeladen. Der DNS verweist auf Cloudfront, die den S3-Bucket als Ursprung verwendet. Cloudfront kümmert sich um Verschlüsselung und Komprimierung. Ich habe Cloudfront angewiesen, Objekte automatisch zu komprimieren. Das hat gut funktioniert, bis ich beschloss, einige der verwendeten Bilder von PNG in SVG zu ändern.

Jedes Mal, wenn eine Datei als unkomprimiert angefordert wird es geliefert wird, wie mit dem eingestellten Content-Type (image/svg + xml) und die Seite gerendert wird korrekt ist. Wenn die Datei jedoch als komprimiert angefordert wird, wird sie mit dem Standard-Inhaltstyp (application/octet-stream) geliefert und das Bild fehlt beim Rendern. Wenn ich dann mit der rechten Maustaste auf das Bild klicke und das Bild in einem neuen Tab öffne, wird es korrekt angezeigt (ohne den Rest der Seite).

Das Ergebnis ist das gleiche unabhängig von dem verwendeten Browser. In Firefox weiß ich, wie man es auffordert, komprimierte oder unkomprimierte Seiten anzufordern. Ich habe auch versucht, die Header zu überprüfen. Dies sind die Ergebnisse:

λ curl --compressed -v -o /dev/null http://dev.example.com/img/logo-6998bdf68c.svg 
* STATE: INIT => CONNECT handle 0x20049798; line 1090 (connection #-5000) 
* Added connection 0. The cache now contains 1 members 
* Trying 52.222.157.200... 
* STATE: CONNECT => 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 => SENDPROTOCONNECT handle 0x20049798; line 1240 (connection #0) 
* STATE: SENDPROTOCONNECT => DO handle 0x20049798; line 1258 (connection #0) 
> GET /img/logo-6998bdf68c.svg HTTP/1.1 
> Host: dev.example.com 
> User-Agent: curl/7.44.0 
> Accept: */* 
> Accept-Encoding: deflate, gzip 
> 
* STATE: DO => DO_DONE handle 0x20049798; line 1337 (connection #0) 
* STATE: DO_DONE => WAITPERFORM handle 0x20049798; line 1464 (connection #0) 
* STATE: WAITPERFORM => PERFORM handle 0x20049798; line 1474 (connection #0) 
* HTTP 1.1 or later with persistent connection, pipelining supported 
< HTTP/1.1 200 OK 
< Content-Type: application/octet-stream 
< Content-Length: 7468 
< Connection: keep-alive 
< Date: Wed, 01 Mar 2017 13:31:33 GMT 
< x-amz-meta-cb-modifiedtime: Wed, 01 Mar 2017 13:28:26 GMT 
< Last-Modified: Wed, 01 Mar 2017 13:30:24 GMT 
< ETag: "6998bdf68c8812d193dd799c644abfb6" 
* Server AmazonS3 is not blacklisted 
< Server: AmazonS3 
< X-Cache: RefreshHit from cloudfront 
< Via: 1.1 36c13eeffcddf77ad33d7874b28e6168.cloudfront.net (CloudFront) 
< X-Amz-Cf-Id: jT86EeNn2vFYAU2Jagj_aDx6qQUBXFqiDhlcdfxLKrj5bCdAKBIbXQ== 
< 
{ [7468 bytes data] 
* STATE: PERFORM => 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 

und für unkomprimiertes es sieht besser aus:

λ curl -v -o /dev/null http://dev.example.com/img/logo-6998bdf68c.svg 
* STATE: INIT => CONNECT handle 0x20049798; line 1090 (connection #-5000) 
* Added connection 0. The cache now contains 1 members 
* Trying 52.222.157.203... 
* STATE: CONNECT => 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 => SENDPROTOCONNECT handle 0x20049798; line 1240 (connection #0) 
* STATE: SENDPROTOCONNECT => DO handle 0x20049798; line 1258 (connection #0) 
> GET /img/logo-6998bdf68c.svg HTTP/1.1 
> Host: dev.example.com 
> User-Agent: curl/7.44.0 
> Accept: */* 
> 
* STATE: DO => DO_DONE handle 0x20049798; line 1337 (connection #0) 
* STATE: DO_DONE => WAITPERFORM handle 0x20049798; line 1464 (connection #0) 
* STATE: WAITPERFORM => PERFORM handle 0x20049798; line 1474 (connection #0) 
* HTTP 1.1 or later with persistent connection, pipelining supported 
< HTTP/1.1 200 OK 
< Content-Type: image/svg+xml 
< Content-Length: 7468 
< Connection: keep-alive 
< Date: Wed, 01 Mar 2017 20:56:11 GMT 
< x-amz-meta-cb-modifiedtime: Wed, 01 Mar 2017 20:39:17 GMT 
< Last-Modified: Wed, 01 Mar 2017 20:41:13 GMT 
< ETag: "6998bdf68c8812d193dd799c644abfb6" 
* Server AmazonS3 is not blacklisted 
< Server: AmazonS3 
< Vary: Accept-Encoding 
< X-Cache: RefreshHit from cloudfront 
< Via: 1.1 ac27d939fa02703c4b28926f53f95083.cloudfront.net (CloudFront) 
< X-Amz-Cf-Id: AlodMvGOKIoNb8zm5OuS7x_8TquQXzAAXg05efSMdIKgrPhwEPv4kA== 
< 
{ [2422 bytes data] 
* STATE: PERFORM => 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 

Ich mag nicht die Kompression aus Performance-Gründen auszuschalten. Und es sieht so aus, dass dies nur für SVG-Dateitypen passiert. Alle anderen Arten haben die richtige, dh. der gleiche Inhalt-Typ. Ich habe bereits versucht, den Cache zu entwerten und sogar komplett abzuschalten, indem ich die Cache-Zeit auf 0 Sekunden eingestellt habe. Ich kann beim Hochladen auf S3 keine komprimierte Version hochladen, da der Uploadvorgang automatisiert ist und nicht einfach für eine einzelne Datei geändert werden kann.

Ich hoffe, dass ich etwas falsch gemacht haben, denn das wäre am einfachsten zu fixieren. Aber ich habe keine Ahnung, was mit der Einstellung falsch sein könnte. Ich habe Google bereits verwendet, um jemanden zu finden, der ein ähnliches Problem hat, aber es sieht so aus, als wäre es nur ich. Wer hat eine Idee?

Answer 1

Sie haben das Problem falsch diagnostiziert. CloudFront ändert die Content-Type nicht.

Cloudfront, jedoch tut Cache verschiedene Versionen des gleichen Objekts, basierend auf Variationen in der Anfrage.

Wenn Sie bemerken, Ihre Last-Modified mal auf diese Objekte sind unterschiedlich. Sie hatten ursprünglich den Inhaltstyp in S3 falsch eingestellt. Sie haben das nachträglich behoben, aber CloudFront merkt nicht, dass sich die Metadaten geändert haben, da sich der ETag nicht geändert hat. Sie erhalten also falsche Antworten. Es wird die ältere Version für Anfragen bereitgestellt, die Unterstützung für die Unterstützung von gzip-Kodierungen bieten. Wenn sich die tatsächliche Nutzlast des Objekts geändert hätte, hätte CloudFront wahrscheinlich bereits seinen Cache aktualisiert.

ein invalidation Sie den Cache und innerhalb von wenigen Minuten zu reinigen, sollte dieses Problem weggehen.