【发布时间】：2019-08-19 12:16:14
【问题描述】：
我正在做一些对overcome a limitation with request and response behavior 来说可能不寻常且不明智的事情。
我正在通过https.get 对初始 URL 进行 Origin Request Lambda 回调，并在标头中传递了一个参数。这将导致同一 URL 请求的次要行为，允许我在返回自定义响应之前改变原始 Origin Request Lambda 中的响应。
长版：
Viewer Request Lambda 的函数 1 在标题中没有自定义属性
my-uuid时触发。它将创建 UUID，在标头的my-uuid属性中设置该 UUID，然后使用更新的标头触发回调。Origin Request Lambda 的函数 1 在存在
my-uuid标头 时触发。 Cloudfront 配置为仅基于此标头进行缓存，因此生成的 UUID 将始终触发 Origin Request Lambda 的 Function 1。函数 1 对原始请求中调用的 URL 进行https.get调用，但传递了my-uuid标头。Viewer Request Lambda 的函数 2 基于第二次运行中
my-uuid标头的存在而触发。这只是去除my-uuid标头并触发没有my-uuid标头属性的回调。该页面之前已被调用，并且位于 Cloudfront 缓存中。由于请求没有
my-uuid标头属性，因此没有缓存清除，缓存页面返回给Origin Request Lambda的函数1。或者：这个页面还没有被缓存，所以调用Origin Request Lambda的Function 2。在没有
my-uuid标头属性的情况下，它只是按原样触发带有请求的回调。
无论哪种方式，Origin Request Lambda 的函数 1 从
https.get调用接收 HTML，并使用它来创建具有所需页面正文的自定义响应对象，但还有包含我在初始 Viewer Request Lambda 中生成的 UUID 的 set-cookie 标头。这个自定义响应对象被传递到回调中。
在这条路上，我精心设计的解决方案让我遇到了另一个问题：
当我通过 Postman 调用我的端点时，步骤 3 和 4.2（Request Lambda 的函数 2）根本没有记录。我有大量的控制台日志来跟踪内部发生的事情。但是，响应具有我尝试在最终响应中设置的任何标头（令人讨厌的是，set-cookie 标头似乎只是消失了，这就是我需要日志记录工作的原因）。
如果我在我的 Postman 请求中设置 my-uuid 标头以触发功能 2 行为，我确实会在日志中看到这些。
【问题讨论】：
-
嗯，我不能指责你没有尝试跳出框框思考......但最终还不清楚你为什么会经历所有这些回旋。设置不存在的 cookie 的正确方法是将 30 倍重定向返回到与
Set-Cookie相同的 URI。但是，如果您坚持不这样做，则使用查看器请求触发器将 cookie 注入请求中，然后在查看器响应触发器中发出具有相同值的Set-Cookie。 -
（查看器响应触发器可以访问请求对象，因为它在被查看器请求触发器修改后存在于同一 HTTP 事务中）。
-
您可以尝试在原始响应 lambda@edge 函数本身中添加 set-cookies 吗？然后它也可以用作缓存键。
-
@Michael-sqlbot 您如何访问查看器响应中的请求对象？我一直在寻找两个星期，整个解决方法是因为我无法弄清楚（理想情况下不想做重定向）
-
@RandyHall 请求在response event 中的相同位置，因为它是请求事件
event.Records[0].cf.request。在查看器响应触发器中，这部分结构包含 “CloudFront 从查看器收到的请求，并且可能已被查看器请求事件触发的 Lambda 函数修改。”
标签： amazon-web-services aws-lambda