Передача User-Agent через Cloudfront для скребка Facebook
Этот вопрос является пограничным стековым потоком / ошибкой сервера, так что не держите его против меня, что он здесь, пожалуйста:)
У меня есть сервис, размещенный на AWS, nginx с node.js за ним. У меня есть настройка распространения облачного фронта для обслуживания запросов, источником которых является служба (чтобы иметь возможность расти без добавления серверов приложений)
Amazon предлагает отфильтровывать большинство заголовков от переадресованных запросов при настройке облачных распределений, в частности, User-Agent, который, как они утверждают, может сильно различаться, что снижает эффективность настройки CDN.
Это прекрасно работает в большинстве случаев, за исключением случаев, когда вы пытаетесь поделиться страницами на Facebook, и в этом случае мне нужно знать, что пользовательский агент на самом деле Facebook (facebookexternalhit / 1.1 (+ http://www.facebook.com/externalhit_uatext.php)) чтобы иметь возможность вернуть пользовательский ответ.
Я бы создал специальный путь для общего доступа к Facebook, чтобы использовать настраиваемое поведение облачного фронта для таких случаев, но, к сожалению, я не могу контролировать действия пользователей, поэтому общий URL-адрес может совпадать с "обычным" URL-адресом сервера.
Предложения?
1 ответ
Если вам нужно знать user-agent для одного случая, вы мало что можете сделать, кроме внесения в белый список User-Agent: заголовок в соответствующем поведении CloudFront.
CloudFront кэширует ответы по заголовкам запросов, которые он отправляет, поэтому чистый результат будет таким, что для данного запроса будет кэшированный ответ, который был получен путем пересылки запроса с User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 CloudFront не будет считаться пригодным для использования в будущем запросе на User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.85 Safari/537.36 хотя для всех практических целей это тот же браузер.
Когда вы настраиваете CloudFront для кэширования на основе одного или нескольких заголовков, а заголовки имеют более одного возможного значения, CloudFront пересылает больше запросов на исходный сервер для одного и того же объекта. Это замедляет производительность и увеличивает нагрузку на исходный сервер. Если ваш исходный сервер возвращает один и тот же объект независимо от значения данного заголовка, мы рекомендуем не настраивать CloudFront для кэширования на основе этого заголовка.
- http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html
Фраза "настроить CloudFront для кэширования на основе одного или нескольких заголовков" является синонимом "заголовков белого списка", которые необходимо переслать в источник.
Это причина для пересылки столько, сколько вам нужно - иначе это повредит коэффициенту попадания в кэш, в данном случае из-за различий в User-Agent: Строки, что означает, что вы не в полной мере используете преимущества пограничных кешей, сервер-источник обрабатывает больше запросов и использует большую полосу пропускания между источником и CloudFront... но на самом деле альтернативы нет. CloudFront ничего не взимает за хранение в пограничных кешах, поэтому единственной разницей в стоимости будет то, что найдено в этих других факторах.
Фраза "замедляет производительность" (выше) не означает, что CloudFront становится медленнее - она относится только к уменьшенной вероятности того, что какой-либо конкретный запрос попадет в кэш, из-за различий в возможных значениях заголовка.
Кстати, поведение CloudFront в этом отношении корректно, так как User-Agent: может означать разнообразный ответ, как вы и указали.
Разумное использование шаблонов путей и поведения нескольких кешей - это ключ к наилучшему использованию кеша CDN с учетом описанных вами обстоятельств. Только белый список User-Agent: on path patterns that need it, such as /images/* (which is, of course, a path I just made up) would be advisable. This same advice also applies to cookies and query strings as well as headers. For path patterns where you don't need the cookies and/or query strings, don't enable cookie and/or query string forwarding -- otherwise, cached responses will only be served to users who present the same cookie or for a request where the path and the query string match a cached response -- so, obviously, there would not be a lot of cache hits in such a situation.
Теперь можно использовать политику запроса происхождения.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-origin-requests.html
Это позволяет нам пересылать заголовки источнику, не учитывая их для кэширования. Хотя политику можно настроить по мере необходимости, существует предопределенная политика запроса источника, называемая
Managed-UserAgentRefererHeaders, что делает начало координат
User-Agentзаголовок, видимый в источнике (или при запросе источника, функция Lambda@edge, если на то пошло).