我有一个CloudFront发行版，其中Lambda函数附加到查看器请求挂钩。我正在使用它重定向到规范域（例如www.foo.tld-> foo.tld）。我还设置了分发本身，以重定向HTTP-> HTTPS。
问题在于，这要求客户端可能必须执行2个请求才能获取正确的URL。例如：
http://www.foo.tld/ -> https://www.foo.tld/ (performed by CloudFront)
https://www.foo.tld/ -> https://foo.tld/ (performed by Lambda function attached to viewer request hook)
我希望在1个请求中完成此操作：
http://www.foo.tld/ -> https://foo.tld/
似乎我需要将此功能添加到请求事件中，但是documentation似乎表明该协议未在请求事件中暴露给Lambda函数。
我的问题是：
答案 0 :(得分：1)
侧面说明：更改主机名和的重定向更改可能会出现问题，因为浏览器越来越不接受没有TLS的HTTP行为，因此将来比现在更多。目前，我不知所措地引用了消息来源来对此进行支持，但给人的印象是应避免将直接从System.out.println(tileScores.get('A'));
重定向到http://www.example.com。不过，如果那是您想要的...
CloudFront和Lambda @ Edge支持此操作，但仅在原始请求触发器中支持。
如果在“缓存行为”设置中将https://example.com标头列入白名单，则可以像下面这样访问该值：
CloudFront-Forwarded-Proto const request = event.Records[0].cf.request; // you may already have this
const scheme = request.headers['cloudfront-forwarded-proto'][0].value;
的值为scheme或http。
我有点书呆子，所以我喜欢故障保险。此替代版本将始终将https设置为scheme，并避免由于某些原因而导致头不存在而引发的异常。这可能适合或不适合您的口味：
https只能在Origin Request触发器中完成此操作的原因是，CloudFront实际上不会在内部触发该头，直到Viewer Request触发器已经触发（如果有）之后。
但是还要注意，您几乎可以肯定想要在Origin Request触发器中执行此操作-因为这些触发器的响应可以被缓存...这应该意味着更快的响应和更低的成本。将标头列入白名单还会将其添加到缓存键，这意味着CloudFront将为任何给定页面自动缓存单独的HTTP和HTTPS响应，并且仅针对相同的请求重播它们。