Повторитель Kentico с пользовательским запросом

Обновление: исходный ответ, показанный ниже, был точным, когда он был написан в 2015 году, и является правильным на основе встроенного поведения самого CloudFront. Первоначально весь путь запроса должен существовать в начале координат.

Если URI является /download/images/cat.png, но источник ожидает только /images/cat.png, то поведение кэша CloudFront /download/* не будет делать то, что вы могли бы предположить - шаблон пути поведения кэша предназначен только для сопоставления - совпадающий префикс не удаляется.

Сам по себе CloudFront не предоставляет способ удаления элементов из пути, запрашиваемого браузером при отправке запроса в начало. Запрос всегда отправляется по мере его получения или с дополнительными символами в начале, если указан путь источника.

Однако введение Lambda @ Edge в 2017 году изменяется динамический.

Lambda @ Edge позволяет объявлять триггерные крючки в потоке CloudFront и записывать небольшие функции Javascript, которые проверяют и могут изменять входящий запрос до того, как будет проверен кеш CloudFront (запрос зрителя) или после кеша (запрос источника). Это позволяет вам переписать путь в URI запроса. Например, вы можете преобразовать путь запроса из браузера /download/images/cat.png, чтобы удалить /download, в результате чего запрос отправляется на S3 (или пользовательский orgin) для /images/cat.png.

Это опция не изменяет, какое поведение кэша будет фактически обслуживать запрос, потому что это всегда зависит от пути, запрошенного браузером, - но затем вы можете изменить путь в полете, чтобы фактический запрашиваемый объект находился на пути, отличном от запрашиваемый браузером. Когда он используется в триггере запроса на источник, ответ кэшируется по пути, запрашиваемому браузером, поэтому последующие ответы не нужно переписывать - их можно обслуживать из кеша - и триггер не нужно будет запускать для каждого запроса.

Функции Lambda @ Edge могут быть довольно простыми в реализации. Вот примерная функция, которая удалит первый элемент пути, каким бы он ни был.

'use strict';

// lambda@edge Origin Request trigger to remove the first path element

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;           // extract the uri
    request.uri = request.uri.replace(/^\/[^\/]+\//,'/');  // modify the uri
    return callback(null,request);                         // return control to CloudFront
};

Вот и все. В .replace(/^\/[^\/]+\//,'/') мы сопоставляем URI с регулярным выражением, которое соответствует ведущему /, за которым следуют 1 или более символов, которые не должны быть /, а затем еще один / и заменяют весь матч на один / - поэтому путь переписан с /abc/def/ghi/... на /def/ghi/... независимо от точного значения abc. Это может быть более сложным в соответствии с конкретными требованиями без какого-либо заметного увеличения времени выполнения ... но помните, что функция Lambda @ Edge привязана к одному или нескольким поведениям кэша, поэтому вам не нужна одна функция для обработки все запросы, проходящие через дистрибутив, - это просто запрос, сопоставляемый шаблоном пути поведения связанного кэша.

Чтобы просто добавить префикс в запрос от браузера, настройка пути источника может по-прежнему как указано ниже, но для удаления или изменения компонентов пути требуется Lambda @ Edge, как указано выше.

Оригинальный ответ .

Да, шаблоны должны существовать в начале координат.

CloudFront, изначально. может добавить к пути для данного источника, но в настоящее время он не имеет возможности удалять элементы пути (без Lambda @ Edge, как отмечено выше).

Если ваши файлы были в /secret/files/ в начале координат, вы могли бы преобразовать шаблон пути /files/* перед отправкой запроса в начало координат, установив «путь происхождения».

Противоположность неверна. Если файлы были в /files в начале координат, не существует встроенного способа обслуживания этих файлов из шаблона пути /download/files/*.

Вы можете добавить (префикс), но не отнять.

Относительно простой обходной путь будет обратным прокси-сервером на экземпляре EC2 в том же регионе, что и ведро S3, указывая CloudFront на прокси-сервер и прокси-сервер на S3. Прокси-сервер будет переписывать HTTP-запрос на своем пути к S3 и передавать результирующий ответ обратно в CloudFront. Я использую такую ​​установку, и это никогда не разочаровывало меня в производительности. (Обратное программное обеспечение прокси, которое я разработал, может фактически проверять несколько ведер параллельно или последовательно и возвращать первый ответ без ошибок, который он получает, CloudFront и запросчик).

Или, если использовать конечные точки сайта S3 как пользовательское происхождение, вы можете использовать правила маршрутизации перенаправления S3, чтобы вернуть перенаправление на CloudFront, отправив браузер обратно с удаленным необработанным префиксом. Это будет означать дополнительный запрос для каждого объекта, увеличивая время ожидания и стоимость, но правила перенаправления S3 могут быть настроены на срабатывание только тогда, когда запрос фактически не соответствует файлу в ведре. Это полезно для перехода от одной иерархической структуры к другой.

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html

http://docs.aws.amazon.com/AmazonS3/latest/dev/HowDoIWebsiteConfiguration.html