我们正在运行一个与 API 通信的 SPA。两者都通过 Cloudfront 向公众公开。
我们现在遇到的问题是,我们在后端看到的请求被 Cloudfront 屏蔽了。含义:
因此 Cloudfront 以某种我们没有预料到的方式拦截了请求。
我已经完成了这些步骤:https://aws.amazon.com/premiumsupport/knowledge-center/configure-cloudfront-to-forward-headers/但最终切断了 API 和前端之间的连接。
我们不关心缓存影响(我们没有很多流量),我们只需要正确的字段显示在后端。
默认情况下,大多数请求标头都会被删除,因为 CloudFront 的默认行为通常是围绕最佳缓存设计的。 CloudFront 的默认标头处理行为已记录。
如果您需要在源端查看特定标头,请将这些标头列入白名单以便在缓存分发中转发。该文档将此称为“选择您希望 CloudFront 进行基础缓存的标头”——这就是它的作用——但该描述掩盖了实际发生的情况。 CloudFront 会删除其余标头,因为它无法确定具有特定值的特定标头是否可能更改源生成的响应。如果默认情况下不删除这些标头,则当用户看到从缓存提供的“错误”响应时,另一个方向上会出现混乱。 就您而言,您几乎肯定不希望将
Host
标头包含在转发白名单中。
特别是在测试时,请确保您还将错误缓存最小 TTL 设置为 0
,因为默认值是 300 秒...因此修复后最多 5 分钟内您无法看到问题是否已修复它。此默认值也是设计使然,这是一种保护措施,以避免可能继续失败的请求使您的源超载。 检查来自 CloudFront 的响应时,请留意
Age
响应标头,该标头在从缓存提供响应时随时出现。它告诉您自 CloudFront 获得当前返回给您的响应以来已经过去了多长时间(以秒为单位)。
如果您想禁用 CloudFront 缓存,您可以将最大、最小和默认 TTL 全部设置为 0(这仅影响 2xx 和 3xx HTTP 响应 - 错误会缓存不同的时间窗口,如上所述),或者您的源可以一致返回
Cache-Control: s-maxage=0
,这将阻止 CloudFront 缓存响应。