AWS CloudFront - 转发用户代理但不缓存它

Question

我希望我的来源能够看到 User-Agent 标头。例如：Gecko/20100101 Firefox/62.0 而不是 Amazon CloudFront。

在“行为”选项卡中，我可以将 User-Agent 标头列入白名单，因此它可以正确传递到源，但是现在 CloudFront 会根据 User-Agent 缓存内容，这意味着用户从不同浏览器访问 CloudFront 端点会强制 CloudFront 转到源.

是否有任何方法可以配置 CloudFront 以将一些标头传递给源，但不一定针对它们进行缓存？

编辑： Accept-Language 标头有类似的问题。我想将它传递给原点，但我不想缓存它。我正在缓存的资产不依赖于语言，但不可缓存的内容取决于 Accept-Language 标头。

Answer 1

您可以使用分配给您的 CloudFront 分配的 Lambda@Edge 函数 (https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html)。你需要两个函数：

1. Viewer-Request 事件处理程序，它将读取 User-Agent 标头并将其复制到例如X-My-User-Agent。在来自客户端的请求到达您的 Cloudfront 分发之前调用 Viewer-Request 处理程序。
2. Origin-Request 事件处理程序，它将读取X-My-User-Agent 并替换User-Agent。当 Cloudfront 在其缓存中未找到请求的页面并将请求发送到源时，将调用 Origin-Request 处理程序。

请注意，您不应将 User-Agent 添加到 Cloudfront 白名单：

您可以将 CloudFront 配置为根据 Date 和 User-Agent 标头，但我们不推荐它。这些标题 有很多可能的值，并且基于它们的值进行缓存会 导致 CloudFront 将更多请求转发给您的 产地。

参考：https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#request-custom-headers-behavior

Viewer-Request 处理程序示例（Lambda@Edge 只能用 NodeJS 或 Python 编写，参考：https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-requirements-limits.html#lambda-requirements-lambda-function-configuration）：

'use strict';

exports.handler = (event, context, callback) => {
  const request = event.Records[0].cf.request;
  const headers = request.headers;
  const customUserAgentHeaderName = 'X-My-User-Agent';
  const userAgent = headers['user-agent'][0].value;

  headers[customUserAgentHeaderName.toLowerCase()] = [
    {
      key: customUserAgentHeaderName,
      value: userAgent
    }
  ];


  callback(null, request);
};

Origin-Request 处理程序示例：

'use strict';

exports.handler = (event, context, callback) => {
  const request = event.Records[0].cf.request;
  const headers = request.headers;
  const customUserAgentHeaderName = 'X-My-User-Agent';
  const realUserAgent = headers[customUserAgentHeaderName.toLowerCase()][0].value;

  headers['user-agent'] = [
    {
      key: 'User-Agent',
      value: realUserAgent
    }
  ];


  callback(null, request);
};

Answer 2

如果请求在不同的用户代理之间缓存，在命中的情况下，真实用户代理根本不会被传递到源端。 CloudFront 只会返回缓存的响应。

您提到您喜欢将用户代理信息发送到 Elasticsearch。除非您只对丢失的请求感兴趣，否则您不能依赖从源应用程序收集的日志。

如果您有 Lambda@Edge 以 realUserAgent 的形式发送用户代理，但用户代理标头本身不是缓存参数，则在 Miss 的情况下，源仍然不会接收该数据。

我在这里看到的唯一解决方案是使用从 CloudFront 生成的访问日志。 CloudFront 访问日志不仅包含用户代理，还包含 IP 地址和其他有用信息。此数据会同时记录 Hit 和 Miss。设置 logstash 以将此信息发送到 Elasticsearch 也很容易。

• [1]https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html
• [2]https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-logs-elasticsearch/

Answer 3

亚马逊似乎在 2020 年 7 月左右推出了新功能“来源请求政策”。您应该可以使用它（不会在 Lambda@Edge 中陷入困境）：https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-cloudfront-announces-cache-and-origin-request-policies/

TLDR：

随着时间的推移，我们看到了许多新功能可能对客户有用的案例。例如：

• 将诸如 User-Agent 之类的信息转发到源以进行分析/记录，但不会根据设备类型提供不同的内容变体（现在您可以转发 user-agent 标头并将其从缓存键中排除）

^ 这是你的用例 :)

Answer 4

这可能是一个简单的解决方案。如果您希望将 User-Agent 用于唯一类型的 URL 示例，/tracking/a,/tracking/b 像这样为此路径 [tracking*] 创建一个新分配，并将此分配的 User-Agent 列入白名单。因此，您不会对所有 url 的 AWS 缓存感到困惑，而只是对这条路径进行缓存。