Мой веб-сайт размещен на S3 с CloudFront в качестве CDN, и мне нужно, чтобы эти два URL-адреса работали одинаково и обслуживали файл index.html в каталоге:
example.com/directory example.com/directory/
Тот, у кого / в конце неправильно предлагает браузеру загрузить файл с нулевым байтом со случайным хешем для имени файла. Без косой черты он возвращает мою страницу 404.
Как я могу получить оба пути для доставки файла index.html в каталог?
Если есть способ, которым я «должен» это делать, отлично! На это я надеюсь, но если нет, я, вероятно, попробую использовать Lambda @ Edge для перенаправления. Мне это все равно нужно для некоторых других ситуаций, поэтому некоторые инструкции о том, как сделать 301 или 302 редирект с Lambda @ Edge, тоже будут полезны :)
Обновление (согласно комментарию Джона Хэнли)
curl -i https://www.example.com/directory/
HTTP/2 200
content-type: application/x-directory
content-length: 0
date: Sat, 12 Jan 2019 22:07:47 GMT
last-modified: Wed, 31 Jan 2018 00:44:16 GMT
etag: "[id]"
accept-ranges: bytes
server: AmazonS3
x-cache: Miss from cloudfront
via: 1.1 [id].cloudfront.net (CloudFront)
x-amz-cf-id: [id]
Обновить
CloudFront имеет одно поведение: пересылка http на https и отправка запросов на S3. У меня также есть маршрут ошибки 404 на вкладке ошибок.
Вы пробовали получить доступ к каталогу непосредственно на S3, не заходя через облачный интерфейс - похоже ли поведение?
На самом деле я гарантирую, что все ссылки на подкаталоги заканчиваются явным index.html, чтобы избежать проблемы. Другой вариант - хранить каждый подкаталог в отдельной корзине за облачным фронтом - index.html в качестве объекта по умолчанию - это параметр S3, который «я думаю» применяется только к корневому каталогу корзины.
Лямбда @ edge может переписать запрос вместо перенаправления пользователя. т.е. притворяться Index.html каждый раз, когда GET-запросы заканчиваются на /. Но, боюсь, это не очень элегантно.
В любом случае для этих бессерверных архитектур lambda @ edge, похоже, является местом для наших конфигураций веб-серверов, которые мы традиционно помещали в Nginx или Apache.