У меня есть веб-сайт, размещенный на 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 вместо имени хоста корзины. В случае OP желаемое происхождение будет.
mysite.s3-website-us-east-1.amazonaws.com
Попадание в дистрибутив Cloudfront с использованием только корзины в качестве источника не работает, потому что корзина фактически не обслуживает перенаправления. Он обслуживает только файлы и хранит метаданные.
Надеюсь, это поможет.
Согласно документально подтвержденным Поведение запросов и ответов, а также поддерживаемые коды состояния HTTP для настраиваемых источников, Amazon CloudFront не следует Перенаправления, К сожалению:
[...] После настройки перенаправления в первый раз, когда конечный пользователь отправляет запрос на объект, CloudFront Front отправляет запрос источнику, а источник отвечает перенаправлением (например, 302 перемещено временно). CloudFront кэширует перенаправление и возвращает его конечному пользователю. CloudFront не выполняет перенаправление. [курсив мой]
Конечно, вы используете Amazon S3 а не настраиваемое происхождение, и связанный раздел заметно отсутствует в Поведение при запросе и ответе для Amazon S3 Origins, но, учитывая, что перенаправления Amazon S3 были добавлены совсем недавно (см. Amazon S3 - поддержка перенаправления веб-сайтов), он может просто отсутствовать там.
Соответственно, я рискну предположить, что вы не получаете пустой файл с кодом состояния HTTP. 200 ОК, скорее статус HTTP 301 перемещен навсегда без тела вообще - проверяли ли вы это с помощью браузера или, в конечном итоге, только с помощью инструмента командной строки, например, cURL или HTTPie? Последние инструменты обычно требуют явного параметра для отслеживания перенаправлений, поэтому это может легко остаться незамеченным.
Если анализ окажется правильным, вам нужно будет настроить перенаправление для явного нацеливания на CloudFront, снова см. Перенаправления:
Вы можете настроить свой веб-сервер для перенаправления запросов в одно из следующих мест:
Новый URL-адрес объекта на исходном сервере. Когда конечный пользователь следует перенаправлению на новый URL-адрес, конечный пользователь обходит CloudFront и переходит прямо к источнику. В результате мы рекомендуем не перенаправлять запросы на новый URL-адрес объекта в источнике.
Новый URL-адрес CloudFront для объекта. Когда конечный пользователь отправляет запрос, содержащий новый URL-адрес CloudFront, CloudFront получает объект из нового местоположения в вашем источнике, кэширует его в периферийном местоположении и возвращает объект конечному пользователю. Последующие запросы на объект будут обслуживаться краевым местоположением. Это позволяет избежать задержки и нагрузки, связанной с тем, что зрители запрашивают объект из источника. Однако при каждом новом запросе объекта взимается плата за два запроса к CloudFront.