服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 通过Cloudfront为Facebook刮板传递User-Agent
Intereting Posts
服务器核心2012上的Windows更新 缓冲的nginx / varnish访问日志到远程服务器 大的named.run文件 Freeradius VLAN分配与EAP-TLS和WiFi 802.1x 如何主动检测受感染的Exchange 2010帐户？ 思科ASA：允许build立的stream量恢复 抓住所有的电子邮件，并将它们全部pipe理到一个脚本与后缀 无法在Windows Server上写入输出文件错误 Cloudformation ELB Cloudwatch警报数据不足 nginx重写规则来replace.php结尾符合/ 在UNIX系统上进行审计 有谁知道如何使用TeamCity的Bazaar仓库？ 在SonicWALL上search对象（NSA 2600，SonicOS 6.1） 如何在Nginx服务器上将所有域（通用/每域）redirect到HTTPS？ 改变主机，我可以转发从logging到另一个IP的stream量？

通过Cloudfront为Facebook刮板传递User-Agent

这个问题是边界线stackoverflow /服务器错误，所以不要抱着它，这是在这里请:)

我有一个服务托pipe在AWS上，nginx与node.js后面。 我有一个cloudfront发行版设置来服务请求的起源是服务（能够增长而不添加应用程序服务器）

亚马逊build议在设置cloudfront发行版（特别是User-Agent）时从转发的请求中筛选大多数标题，声称它们可能会有很大的差异，从而降低CDN设置的有效性。

这对大多数情况下效果很好，除了试图在Facebook上共享页面，在这种情况下，我需要知道用户代理实际上是Facebook（facebookexternalhit / 1.1（+ http://www.facebook.com/externalhit_uatext.php ） ）能够返回自定义响应。

我会为facebook共享创build一个特殊path，以便在这种情况下使用自定义的云端行为，但不幸的是，我无法控制用户将要执行的操作，因此共享url可能与“常规”服务器URL相同。

build议？

如果您需要了解某个用例的用户代理，则除了将相关CloudFront行为中的User-Agent:标题列入白名单之外，您几乎无能为力。

CloudFront会caching它发送的请求头的响应，所以最终的结果将是对于给定的请求，通过使用User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36转发请求获得的caching响应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请求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尽pipe实际上，它是相同的浏览器。

当您将CloudFrontconfiguration为基于一个或多个标头进行caching并且标头具有多个可能的值时，CloudFront会将更多请求转发到您的原始服务器以获取同一对象。 这会降低性能并增加原始服务器上的负载。 如果源服务器返回的是同一个对象，而不pipe给定头的值如何，我们build议您不要根据该头configurationCloudFront进行caching。

– http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html

短语“将CloudFrontconfiguration为基于一个或多个标头进行caching”与将“白名单标题”转发至原点的含义是同义的 。

这就是为什么只有你需要转发的原因 – 否则会伤害你的caching命中率，在这种情况下，由于User-Agent:string的变化，这意味着你没有得到边缘的全部好处caching中，原始服务器处理的请求数量更多，原始数据和CloudFront之间使用的带宽更多…但是没有其他select。 CloudFront不会收取任何费用在边缘caching中存储，因此唯一的成本差异是其他因素中的任何一个。

上面这个短语“减慢性能”并不意味着CloudFront会变慢 – 它只是指由于可能的标题值的变化，任何特定请求被caching命中的可能性降低。

顺便说一句，CloudFront的行为是正确的，在这方面，因为不同的User-Agent:可能意味着不同的响应，就像您已经指出的那样。

考虑到您所描述的情况，明智地使用path模式和多个caching行为是获得CDNcaching最佳使用的关键。 只有将User-Agent:列入白名单User-Agent:在需要它的path模式上，比如/images/* （当然，这是我刚刚创build的path）将是明智的。 同样的build议也适用于cookie和查询string以及标题。 对于不需要cookie和/或查询string的path模式，不要启用cookie和/或查询string转发 – 否则，caching的响应只会提供给呈现相同cookie或请求的用户path和查询string匹配一个caching响应 – 显然，在这种情况下不会有很多caching命中。