Ich habe eine PHP-App auf AWS Elastic Beanstalk, ich habe einen Assets-Bucket auf S3 erstellt. Ich versuche, eine Cloudfront-Verteilung mit Verhaltensweisen einzurichten, um Anforderungen für Assets/* an S3 mit einem Standardverhalten zum Senden von Anforderungen an EB zu senden. Die Domain verweist auf Cloudfront.AWS Cloudfront-Verhalten funktioniert nicht wie erwartet
Alle Anfragen gehen an EB, die einen 404 zurückgibt, da in der EB-Umgebung kein Asset-Verzeichnis vorhanden ist.
Ich habe zwei Cloudfront-Ursprünge erstellt, einen für EB und einen für den S3-Bucket. Dies ist, was mein Verhalten wie folgt aussehen:
Precedence Path Pattern Origin Protocol Policy Fwd Query Strings
0 assets/* S3-example-bucket HTTP and HTTPS No
1 Default (*) Custom-example.us-east-1.elasticbeanstalk.com HTTP and HTTPS Yes
Es scheint, als ob diese nach vorne ziemlich gerade sein sollte, so nehme ich an mir fehlt etwas Grundsätzliches. Jede Hilfe wird sehr geschätzt.
Edit:
Anforderungs-Header:
GET /assets/images/10waysaudiobook.png HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: wordpress_logged_in_8a27500b7747be1e4fbad7f473f238e5=snickerspixy%7C1466021823%7Cr7rE5moINjanjHEqb1TGbsSkn9F7OCZLfX69IbcnGJu%7C28fc452885f3fe6e954243abab585a188f6511cdd6eeec6fa5ec5c50b9f3d393; wp-settings-7674=m4%3Do%26m5%3Do%26m9%3Do%26m6%3Do%26editor%3Dhtml%26m10%3Do%26m0%3Do%26m3%3Do%26hidetb%3D1%26m2%3Dc%26m1%3Do%26m8%3Do%26m12%3Do%26m7%3Do%26m11%3Do%26urlbutton%3Dnone%26m13%3Do%26tml1%3D1%26imgsize%3Dfull%26align%3Dcenter%26libraryContent%3Dbrowse%26ed_size%3D569%26unfold%3D1%26wplink%3D1%26mfold%3Do%26post_dfw%3Doff%26advImgDetails%3Dshow%26posts_list_mode%3Dlist; wp-settings-time-7674=1464816549; AWSELB=1FCB85F51606EBAFF15FEADB01C8069AEDE17E2A043407E615EF1A0E1ABF24607545A45D3DC206631F7AAE4503ADA423788B5E6B5B48FAE93EE916DE068509E64F92AC10FF; PHPSESSID=cpi2su7s967phu87rlpjgneel6; wordpress_test_cookie=WP+Cookie+check
Connection: keep-alive
Antwort-Header:
HTTP/1.1 404 Not Found
Cache-Control: no-cache, must-revalidate, max-age=0
Content-Type: text/html; charset=UTF-8
Date: Sun, 05 Jun 2016 00:54:23 GMT
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Link: <http://example.com/wp-json/>; rel="https://api.w.org/"
Pragma: no-cache
Server: Apache
Transfer-Encoding: chunked
Connection: keep-alive
Die Konfiguration scheint für das von Ihnen beschriebene Verhalten korrekt zu sein. Der führende Schrägstrich wird von CloudFront nicht benötigt ('assets/*' ist äquivalent zu '/ assets/*'), also sollte es nicht so sein. Ziehen Sie in Betracht, die Request- und Response-Header für eine der Anfragen nach etwas in 'assets/*' zu posten, das nicht wie erwartet funktioniert. –
@ Michael-sqlbot Kopfdaten hinzugefügt. Ich habe dort nichts Nützliches gesehen, außer dass es zeigt, dass 404 von WordPress erzeugt wird, also weiß ich, dass es von EC kommt. – BillK
Philosophisch gesehen ist die Information, die * nicht vorhanden ist *, was die Geschichte erzählt: Diese Anfrage ging überhaupt nicht durch CloudFront - du hättest mindestens einen 'Via:' - Header, einen 'X-Cache: 'header, und ein' X-Amz-Cf-Id: 'header, wenn es so war. Vergewissere dich, dass dein DNS auf CloudFront verweist. Wenn das korrekt ist, überprüfe die Antwort und die TTL, wenn du nach dem Hostnamen der Seite suchst - er wurde vielleicht unnötig hoch gesetzt und hat noch nicht genug Zeit, um runterzufallen Der neue Wert kann "propagieren", wenn es sich um eine aktuelle Änderung handelt. –