Невозможно обслужить статический файл, используя фронт облака с сервером происхождения как экземпляр ec2 - PullRequest
Новая
       13

Невозможно обслужить статический файл, используя фронт облака с сервером происхождения как экземпляр ec2

0 голосов
/ 12 мая 2019

У меня есть веб-приложение, работающее на экземпляре centos ec2 за обратным прокси-сервером Nginx с сертификацией SSL (Let's Encrypt).

У меня есть файл JavaScript, расположенный по URL-адресу, например https://example.com/static/src/js/allEnd.js
Я использовалCloudFront доставил статический файл с сервером происхождения в качестве экземпляра HTTP ec2 (без использования корзины s3).
Мой сервер происхождения сопоставлен с именем домена https://example.com У меня есть следующая конфигурация, которую я до сих пор выполнил:
1. www.example.com перенаправляется на example.com в Nginx
2. URL-адрес CloudFront представляет собой псевдоним моего пользовательского домена, т.е. cdn.example.com
3. SSL для example.com завершенна Nginx, тогда как SSL для cdn, example.com сделан на AWS.

Насколько я понял, впервые CloudFront будет обслуживать статический контент, получая файл с моего сервера ec2, а затемвремя, которое он будет выполнять из CloudFront, но каждый раз, когда CloudFront перенаправляет на исходный сервер, чтобы получить статический файл, в котором CloudFront не обслуживается мое дело.

Вот заголовок для исходного сервера и сервера CloudFront.

1. Origin server (https://example.com)
get https://example.com/static/src/js/allEnd.js
HTTP/2 200
server: nginx/1.12.2
date: Sun, 12 May 2019 12:27:50 GMT
content-type: application/javascript
content-length: 168435
etag: "wzsdm-1557567525-168435-283837276"
cache-control: max-age=604800, public
expires: Sun, 19 May 2019 12:27:50 GMT
strict-transport-security: max-age=15768000; includeSubdomains; preload
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
strict-transport-security: max-age=15768000

2. CloudFront with origin as https://example.com (https://cdn.example.com)
get https://cdn.example.com/static/src/js/allEnd.js
HTTP/2 301
content-type: text/html
content-length: 185
location: https://example.com/static/src/js/allEnd.js
server: nginx/1.12.2
date: Sun, 12 May 2019 09:17:40 GMT
strict-transport-security: max-age=15768000; includeSubdomains; preload
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
strict-transport-security: max-age=15768000
age: 17
x-cache: Hit from cloudfront
via: 1.1 76d9b50884e58e2463b175e34e790838.cloudfront.net (CloudFront)
x-amz-cf-id: HBbfJXbFgKQz4eYlQSpLPQAk8pxZRKuGsb6YjFu8-AJL0JwPfs8FZw==

Как видите, заголовок ответа, который cdn.example.com (CloudFront) перенаправляет на источник (example.com).Кроме того, меня смущает content-type:text/html, который должен быть content-type: application/javascript

Каковы возможности, которые я, возможно, неправильно настроил?

Если что-то еще вы хотите узнать, пожалуйста, не стесняйтесь спрашивать.Благодарю.

PS: я новичок в конфигурации Nginx и AWS и, самое главное, в управлении кешем.

1 Ответ

0 голосов
/ 12 мая 2019

Вам понадобится проверить конфигурацию исходного сервера *1002* и файлы журналов, чтобы понять, почему это произошло.

Проверьте журналы исходного сервера, и вы обнаружите, что исходный сервер первоначально сгенерировал ответ 301 перенаправления, а не CloudFront.

Обратите внимание, что заголовки ответа от CloudFront включают server: nginx/1.12.2.CloudFront не добавил это.

Content-Type установлен как есть, потому что ваш исходный сервер также возвратил HTML, говорящий что-то вроде «объект перемещен» или «вы перенаправлены».Современные браузеры обычно не отображают это сообщение, они просто следуют перенаправлению.

В любом случае, если исходный сервер возвращает перенаправление, CloudFront не следует перенаправлению, возвращенному исходным сервером - он просто возвращает перенаправление в браузер.

Одним из возможных объяснений поведения, которое вы видите, является то, что вы установили Политику протокола источника в CloudFront на «Только HTTP» вместо «Только HTTPS» или «Просмотрщик соответствия», поэтому источник пытается перенаправить соединениеиспользовать HTTPS, поскольку он видит входящее соединение (из CloudFront) как HTTP вместо HTTPS.

Другая возможность заключается в том, что вы настроили параметры поведения кэша CloudFront для внесения в белый список заголовка Host для пересылки к источнику.

...