Вопрос в том: Почему невозможно изменить статус http перед возвратом ответов в ViewerResponseEvents в лямбда-крае?
У меня есть лямбда-функция, которая должна проверять каждый ответ и изменять его код состояния на основе файла JSON, который у меня есть в моей лямбда-функции. Я развернул эту лямбда-функцию в Ответ зрителя, потому что хочу, чтобы эта функция выполняла перед возвращением при каждом ответе. В документации Aws ( https://aws.amazon.com/blogs/networking-and-content-delivery/lambdaedge-design-best-practices/ ) сказано, что если вы хотите выполнить функцию для всех запросов, ее следует поместить в события средства просмотра.
Итак, я создал простую функцию, которая в основном клонирует и изменяет код ответа http, прежде чем вернуть его. Я сделал этот код для теста:
exports.handler = async (event) => {
const request = event.Records[0].cf.request;
console.info(request);
console.info(`Original response`);
const response = event.Records[0].cf.response;
console.info(`Original response`);
console.info(response);
//clone response just for change the status code
let cloneResponseReturn = JSON.parse(JSON.stringify(response));
cloneResponseReturn.status = 404;
cloneResponseReturn.statusDescription = 'Not Found';
console.info('Log Clone Response Return');
console.info(cloneResponseReturn);
return cloneResponseReturn;
};
Когда я обращаюсь к журналу в cloudwatch, он показывает, что ответ имеет код http 404, но по какой-то причине cloudfront все еще возвращает ответ с кодом состояния 200. (Я очистил кеш браузеров, проверил его в других инструментах, таких как почтальон, но во всех них CloudFront возвращает HTTP 200)
Распечатка журнала CloudWatch и ответа:
Если я изменю эту функцию на выполнение в исходный ответ, она будет работать, но я не хочу выполнять ее в ТОЛЬКО в кеше промах (+так как aws говорит нам, что исходные события будут выполняться только в этом случае+). Поскольку исходные события выполняются только при промахе кеша, для выполнения этого перенаправления мне пришлось бы создать блокировщик заголовков chache, чтобы убедиться, что исходные события всегда будут выполняться.
Действительно странно такое поведение края лямбда. Кто-нибудь знает, как я могу это решить? Я уже пытался очистить кеш браузеров и инструментов, которые я использую для тестовых запросов, а также очистить кеш моего дистрибутива, но все равно не работает.
Я разместил вопрос на форуме AWS неделю назад, но ответа до сих пор нет: https://forums.aws.amazon.com/message.jspa?messageID=885516#885516
Заранее спасибо.
Важным также является тот факт, что если ответ изменен триггером Origin Response и ответ можно кэшировать, CloudFront кэширует ответ модифицированный. Именно по этой причине триггеры Origin Response не срабатывают при попадании в кэш — это было бы избыточно. Результат триггера, включая любые модификации ответа, — это то, что будет обслуживаться из кэша при последующих запросах, при условии, что ответ считается кэшируемым после завершения триггера.
Понятно! Проблема в том, что я размещаю одностраничное приложение, а index.html не кэшируется, поэтому каждый отдельный запрос к index.html будет промахом кеша. Но проблема в том, что даже для других запросов, которые не кэшируются, я хотел бы изменить код состояния ответа, а не кэшировать его. Жаль, что лямбда Edge не позволяет изменить код состояния http в ответе зрителя. Чтобы решить эту проблему, я использую пакет заголовков кеша, что не очень хорошо, потому что он заставляет облачный фронт хранить несколько версий файла только для того, чтобы всегда выполнять событие ответа источника.





Я считаю, что поведение правильное/ожидаемое — когда срабатывает ответ Viewer, код состояния HTTP для ответа уже завершен внутри CloudFront и не может быть изменен. Но я думаю, вы можете неправильно понять один или два последствия того, что триггеры Origin Response срабатывают только при промахах кеша. Я не вижу значения свойства
Cache-Controls-maxageна вашем снимке экрана, но если это0, то CloudFront не кэширует эти ответы, поэтому вы все равно никогда не попадете в кеш... поэтому каждый запрос будет кешем Мисс.