Чому CloudFront не переглядає місце перенаправлення веб-сайту S3?

У мене розміщений веб-сайт на Amazon S3. Це нова версія старого веб-сайту, розміщеного на WordPress.

Я створив деякі файли з метаданими Website Redirect Locationдля обробки старого місця та перенаправлення їх на нові сторінки веб-сайту.

Наприклад: У мене було http://www.mysite.com/solutionте, що я хочу переспрямувати на. http://mysite.s3-website-us-east-1.amazonaws.com/product.htmlТому я створив порожній файл, названий solutionвсередині мого відра з правильними метаданими:

Website Redirect Location= /product.html

Метадані переадресації S3 еквівалентні 301 Moved Permanentlyвідмінним для SEO. Це чудово працює при доступі до URL безпосередньо з домену S3.

Я також створив дистрибутив CloudFront на основі відра веб-сайту. І коли я намагаюся отримати доступ через свій дистрибутив, перенаправлення не працює, тобто:

http://xxxx123.cloudfront.net/solution не перенаправляє, а завантажує порожній файл.

Отже, моє запитання - як зберегти перенаправлення через дистрибутив CloudFront? Або будь-яка ідея, як впоратися з перенаправленням без погіршення SEO?

Спасибі

Нещодавно я зіткнувся з цією проблемою і знайшов вирішення, яке, здавалося, спрацювало.

Я створив розподіл Cloudfront зі спеціальним походженням, що вказує на статичне ім'я хоста веб-сайту S3 замість імені хоста відра. У випадку з ОП бажане походження було б.

mysite.s3-website-us-east-1.amazonaws.com

Якщо натиснути розповсюдження Cloudfront, просто використовуючи відро, оскільки джерело не працює, тому що відправник не обслуговує переадресації. Він обслуговує лише файли та зберігає метадані.

Сподіваюся, що це допомагає.

Аналіз

Згідно з документально підтвердженою поведінкою запитів і відповідей та підтримуваними кодами статусу HTTP для користувацького походження , Amazon CloudFront не слід переспрямовувати , на жаль:

[...] Після налаштування переадресації перший раз, коли кінцевий користувач подає запит на об’єкт, CloudFront Front надсилає запит на походження, а походження відповідає перенаправленням (наприклад, 302 Moved тимчасово переміщено). CloudFront кешує переспрямування та повертає його кінцевому користувачеві. CloudFront не слідкує за переадресацією. [акцент мій]

Звичайно, ви використовуєте Amazon S3, а не спеціальне походження, і пов'язаний розділ, зокрема, відсутній у поведінці запитів та відповідей для джерел Amazon S3 , але дані перенаправлення Amazon S3 додані лише нещодавно (див. Amazon S3 - Підтримка веб-сайту Переспрямовування ), можливо, це ще просто відсутнє.

Відповідно, я маю на увазі, що ви не отримуєте порожній файл з кодом статусу HTTP 200 ОК , скоріше HTTP-статус 301, переміщений постійно без тіла - чи ви перевіряли це за допомогою браузера чи зрештою лише інструментом командного рядка, наприклад наприклад, CURL або HTTPie ? Останні інструменти зазвичай вимагають явного параметра, щоб слідкувати за переадресаціями, тому це може бути легко непоміченим.

Потенційне рішення

Якщо аналіз виявиться правильним, вам потрібно буде налаштувати переадресацію так, щоб явно націлити CloudFront, знову побачити Переспрямовування :

Ви можете налаштувати веб-сервер для переадресації запитів на одне з наступних місць:

• Нова URL-адреса об'єкта на початковому сервері. Коли кінцевий користувач слідує за переадресацією на нову URL-адресу, кінцевий користувач обходить CloudFront і переходить прямо до початкового коду. Як результат, ми рекомендуємо не перенаправляти запити на нову URL-адресу об'єкта на джерело.

• Нова CloudFront URL для об’єкта. Коли кінцевий користувач подає запит, який містить нову URL-адресу CloudFront, CloudFront отримує об'єкт з нового місця розташування у вашому походження, кешує його в крайовому місці та повертає об'єкт кінцевому користувачеві. Подальші запити на об’єкт будуть обслуговуватися крайовим розташуванням. Це дозволяє уникнути затримки та навантаження, пов’язаної з тим, що глядачі вимагають від об'єкта джерела. Однак кожен новий запит на об’єкт стягуватиме плату за два запити до CloudFront.