0
У меня есть приложение PHP на AWS Elastic Beanstalk, я создал ведро активов на S3. Я пытаюсь настроить дистрибутив Cloudfront с поведением для отправки запросов на активы/* на S3 с поведением по умолчанию для отправки запросов в EB. Домен указывает на Cloudfront.AWS Cloudfront поведение не работает должным образом
Все заявки поступают в EB, который возвращает 404, поскольку в среде EB нет атрибутов активов.
Я создал 2 источника Cloudfront, один для EB и один для ведра S3. Это то, что мое поведение выглядит следующим образом:
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
Кажется, что это должно быть довольно прямо вперед, поэтому я предполагаю, что я что-то основное отсутствую. Любая помощь приветствуется.
Edit:
заголовок запроса:
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
заголовок Ответ:
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
Конфигурация кажется правильной для описанного вами поведения. CloudBlue (обязательный) не является обязательным для косой черты ('assets/*' эквивалентно '/ assets/*'), так что это не должно быть. Рассмотрите возможность размещения заголовков запросов и ответов для одного из запросов на что-то в 'assets/*', который не работает должным образом. –
@ Michael-sqlbot добавил данные заголовка. Я не видел ничего полезного там, кроме того, что он показывает, что 404 создается WordPress, поэтому я знаю, что это происходит от EC. – BillK
Философски говоря, информация, которая * не присутствует *, является тем, что говорит сказку: этот запрос не прошел через CloudFront вообще - у вас был бы, по крайней мере, заголовок 'Via:', 'X-Cache: 'header и заголовок' X-Amz-Cf-Id: ', если бы он был. Убедитесь, что ваш DNS указывает на CloudFront, тогда, если это правильно, проверьте ответ, и TTL увидит, когда вы «выкапываете» имя хоста сайта - возможно, он был установлен излишне высоким и не успел сработать, новое значение может «распространяться», если это недавнее изменение. –