我正在做某事，可能对overcome a limitation with request and response behavior不明智。
我正在通过https.get调用Origin请求Lambda返回初始URL，并在标头中传递了一个参数。这将导致同一URL请求的次要行为，使我可以在返回自定义响应之前，在原始的原始请求Lambda中更改响应。
长版：
my-uuid时，查看器请求Lambda 的功能1会触发。它将创建UUID，在标头的my-uuid属性中设置该UUID，然后使用更新后的标头触发回调。
my-uuid标头 的地方触发 Origin Request Lambda 的功能1。将Cloudfront配置为仅基于此标头进行缓存，以便生成的UUID将始终触发原始请求Lambda的功能1。函数1对原始请求中调用的URL进行https.get调用，但通过my-uuid头传递。
功能2基于第二次运行中my-uuid标头的存在而触发。这只是剥离my-uuid标头，并在没有my-uuid标头属性的情况下触发回调。
此页面已被调用过，位于Cloudfront缓存中。由于请求不具有my-uuid标头属性，因此不存在缓存无效化，并且缓存的页面返回到原始请求Lambda 的功能1。或：
该页面尚未缓存，因此调用了 Origin Request Lambda 的功能2。在没有my-uuid头属性的情况下，它仅按原样触发请求。
无论哪种方式，原始请求Lambda 的功能1都会从https.get调用中接收HTML，并使用此代码创建具有所需主体的自定义响应对象页面，但也是set-cookie标头，其中包含我在初始 Viewer Request Lambda 中生成的UUID。此自定义响应对象将传递到回调中。
在那条路上，我精心设计的解决方案使我遇到了另一个问题：
当我通过Postman呼叫端点时，步骤3和4.2（请求Lambda 的功能2）根本没有记录。我有大量的控制台日志来跟踪内部发生的事情。但是，该响应具有我尝试在最终响应中设置的任何标头（烦人的是，set-cookie标头似乎只是消失了，这就是为什么我需要日志才能工作）。
如果我在邮递员请求上设置my-uuid标头以触发功能2行为，我会在日志中看到这些标头。
答案 0 :(得分：0)
我今天刚遇到同一问题，发现了这个问题。
通过将“转发Cookie” chache行为设置从“无（改善缓存）”更改为“全部转发，基于全部缓存”，我能够使由原始请求Lambda设置的cookie起作用。