AWS Route53 & Lambda: перенаправление незаполненных HTTP-запросов в HTTPS WWW для приложения без сервера
проблема
У меня есть сайт, работающий на "безсерверной" функции AWS Lambda. Route53 направляет запросы к API-шлюзу, который подключается к функции Lambda.
Проблема в том, что вы не можете настроить традиционные перенаправления сервера.
пример
В качестве примера я следовал за этим вопросом / ответом на маршрут http://<my_domain>.com в https://www.<my_domain>.comЯ использую псевдоним записи A для корзины S3, которая настроена как перенаправление статического сайта на https://www.<my_domain>.com,
Вопрос
Как я могу получить https://<my_domain>.com перенаправить на https://www.<my_domain>.com в среде без сервера, как лямбда?
2 ответа
Вам нужно будет выполнить перенаправление в вашей лямбда-функции.
Я уверен, что фактическое имя хоста, использованное в URL, передается в Lambda, возможно, как event.headers.Host, Так что в вашей лямбде вы должны будете сделать что-то вроде этого кода, похожего на python:
def lambda_handler(event, context):
if not event['headers']['Host'].startswith('www'):
return PermanentRedirect('www.'+event['headers']['Host']+event['path'])
Однако на вашем месте я бы указывал имя хоста без www на другой шлюз API с единственным Lambda, предназначенным для перенаправления на www. Тогда в ваших реальных рабочих лямбдах вам не придется беспокоиться о перенаправлениях.
Надеюсь, это поможет:)
Я думаю, что в облачной среде есть настройка для этого. Либо так, либо используйте lambda@edge - так что вы не создаете "настоящие" лямбды.
Другой вариант, который я лично использую, это поставить Cloudflare перед вашим дистрибутивом Cloudfront - конечно, это два CDN, но Cloudflare может сделать эти перенаправления чертовски легко.
Другой вариант - создать два облачных дистрибутива, один для www и другой для не-www, но оба они будут в одном и том же шлюзе API. Не идеально, поскольку преимущества кэширования будут ограничены, но это сработает.