Я делаю что-то необычное и опрометчивое, чтобы преодолел ограничение с помощью запросов и ответов .
У меня есть лямбда-вызов Origin Request к исходному URL через https.get
, с параметром, переданным в заголовке. Это приведет к вторичному поведению для того же URL-запроса, что позволит мне изменить ответ в исходном лямбда-запросе источника перед возвратом пользовательского ответа.
Длинная версия:
Функция 1 из Viewer Request Lambda срабатывает, когда не пользовательское свойство my-uuid
в заголовке. Он создаст UUID, установит этот UUID в свойстве my-uuid
заголовка, а затем сработает обратный вызов с обновленным заголовком.
Функция 1 из Origin Request Lambda срабатывает там, где my-uuid
header присутствует . Cloudfront сконфигурирован для кэширования на основе только этого заголовка, так что сгенерированный UUID всегда будет запускать функцию 1 лямбда-запроса исходного запроса. Функция 1 выполняет https.get
вызов URL-адреса, вызванного в исходном запросе, но переданного по заголовку my-uuid
.
Функция 2 из Viewer Request Lambda срабатывает на основании наличия заголовка my-uuid
во втором запуске. Это просто удаляет заголовок my-uuid
и запускает свойство заголовка обратного вызова sans my-uuid
.
Эта страница была вызвана ранее и находится в кеше Cloudfront. Поскольку в запросе отсутствует свойство заголовка my-uuid
, нет очистки кэша, и кэшированная страница возвращается в функцию 1 лямбда-запроса Origin. ИЛИ:
Эта страница еще не была кэширована, поэтому вызывается функция 2 из Origin Request Lambda . При отсутствии свойства заголовка my-uuid
он просто запускает обратный вызов с запросом как есть.
В любом случае, функция 1 исходного запроса Lambda получает HTML-код из вызова https.get
и использует его для создания пользовательского объекта ответа с телом нужной страницы, но также заголовок set-cookie, содержащий UUID, который я сгенерировал в начальном Запросе просмотра Lambda . Этот объект пользовательского ответа передается в обратный вызов.
Находясь на этом пути, созданное мной решение привело меня к другой проблеме:
Шаги 3 и 4.2 (функция 2 либо Запрос лямбды ) вообще не регистрируются, когда я вызываю свою конечную точку через Почтальона. У меня есть множество консольных журналов, чтобы отслеживать, что происходит внутри. Однако в ответе есть заголовки, которые я пытаюсь установить в окончательном ответе (за исключением, к сожалению, заголовка set-cookie
, который, кажется, просто исчезает, и поэтому мне нужно, чтобы регистрация работала).
Если я установлю заголовок my-uuid
в своем запросе почтальона, чтобы вызвать поведение функции 2, я все равно увижу их в журнале.