AWS - Cloudfront - 如何使用Origin自定义标头 [英] AWS - Cloudfront - How To Use Origin Custom Headers

问题描述

我是AWS的新手，我现在正在经历一些不同的培训课程，我偶然发现的一个有趣的事情是能够在Cloudfront中添加自定义标题。也就是说，我似乎无法弄清楚（或找到简单易懂的文档）如何使用/利用此功能提供的功能。

I'm fairly new to AWS and I'm going through some different training courses right now and one of the interesting things I've stumbled upon is the ability to add Custom Headers in Cloudfront. That said, I can't seem to figure out (or locate simple to understand documentation) as to how to use/leverage the power that this feature offers.

可以有人请告诉我如何：

Can someone please let me know how:

1. 如何访问我设置的标题？例如，我使用终端
   运行一些基本的cURL命令来查看我的Cloudfront
   资源的标题，我假设自定义标题会在那里但是没有
   。


2. 我得到这些自定义标头发送到Origin源
   ，但我很困惑如何使用这些标头来改进
   应用程序/资产逻辑。

如果重要的话我用PHP编程。任何解释，代码示例或有用文档的参考将不胜感激。感谢您的帮助。

If it matters I'm programming in PHP. Any explanations, code examples or references to helpful documentation would be greatly appreciated. Thanks for the help.

推荐答案

如何访问我设置的标题？

How to access the headers that I set?

你浏览器/ curl用户看不到它们。它们在CloudFront和原始服务器之间是私有的，随请求一起发送。

"You" the browser/curl user can't see them. They're private between CloudFront and the origin server, sent with the request.

您可以使用 getallheaders（） 。

You can access them from your server PHP code with getallheaders().

我对如何使用这些标题感到困惑

I'm confused as how to use these headers

他们允许你要做的是两件事之一：

What they allow you to do is one of two things:

• 如果请求中有匹配的标头，它将被发送到原点，但你不希望它发送到收到的，用新值覆盖它

• if a matching header comes in on the request and it would be sent to the origin, but you don't want it sent to the as received, overwrite it with the new value

如果请求中没有匹配的标题，在发送到原始服务器之前添加它。

if a matching header doesn't come in on the request, add it before sending to the origin server.

但是如果你不知道如何处理它们，你可能没有必要。

But if you don't know what to do with them, you may not have a need for them.

一些潜在的申请：

• 如果你想使用签名通过CloudFront URL或签名cookie，您可以添加一个带有秘密值的标头，该标头向您的Web服务器证明该请求来自CloudFront，特别是来自您的 CloudFront分配，因为该值匹配。以前，您的原始服务器必须是公共可访问的，因为无法验证请求是否通过CloudFront（并由CloudFront授权）到达 - 标准标头可能由任何人伪造，即使您检查了传入的IP地址请求，您可以证明它是某些CloudFront分配，但不是您的 CloudFront分配。 （如果您实施了类似的天真信任方案，恶意用户可以设置CloudFront发行版并访问您的内容）。由于浏览器不知道/未看到标题及其值，因此您可以使用代码中用于读取任何其他传入请求标头的相同机制来验证标头是否与预期值一起存在。如果您想要拒绝因某些其他原因未通过CloudFront到达的请求，除了安全内容的身份验证和访问控制之外，也可以使用此方法。请参见 http： //docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/forward-custom-headers.html#forward-custom-headers-restrict-access 。

• If you want to use signed CloudFront URLs or signed cookies, you can add a header with a secret value that proves to your web server that the request came from CloudFront, and specifically from your CloudFront distribution, because the value matches. Previously, your origin server had to be publicly accessible because there was no way of verifying that requests arrived through (and were authorized by) CloudFront -- the standard headers could be forged by anyone, and even if you checked the IP address of the incoming request, you could prove that it was "some" CloudFront distribution, but not your CloudFront distribution. (A malicious user could set up a CloudFront distro and access your content if you implemented a naive trust scenario like that). Since the headers and their values are unknown to/unseen by the browser, you can verify that the header is present with the expected value using the same mechanisms in your code that you'd use to read any other incoming request header. This could also be used if you wanted to deny requests that didn't arrive through CloudFront for some other reason, other than authentication and access control for secure content. See http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/forward-custom-headers.html#forward-custom-headers-restrict-access.

您可以使用它们在去往原点的路上修改CORS标题。请参阅 http：// docs。 aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html#header-caching-web-cors

You could use them to modify CORS headers on the way to the origin. See http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html#header-caching-web-cors

你可以使用如果您有多个CloudFront发行版指向同一个源服务器，它们可以跟踪请求到达的多个CloudFront分配中的哪一个。

You could use them to track which of multiple CloudFront distributions a request arrived through, for billing purposes, if you had multiple CloudFront distros pointed to the same origin server.

您可以使用它们来弥补原始服务器中的某种限制，无论出于何种原因它都需要查看某个标题，但你不想实际转发此标题，因为这会损害你的缓存命中率 - CloudFront根据发送到源的整个请求缓存响应，包括路径，转发标头（如果已启用），查询字符串（如果已启用）和/或cookie（如果已启用）。它只会提供来自缓存的请求，如果它转发到源的请求与它发送的请求完全匹配，以便接收它缓存的响应（因此CloudFront可以根据请求参数缓存同一资源的多个变体）你允许通过转发）。这样做的原因是缓存有义务不对服务器如何根据不同的请求参数改变响应做出假设。除非两个请求在语义上等效，否则它们不能被视为等效缓存目的。

You could use them to make up for some kind of limitation in the origin server, where it needed to see a certain header, for whatever reason, but you didn't want to actually forward this header, since that would hurt your cache hit ratio -- CloudFront caches responses against the entire request sent to the origin, including the path, forwarded headers (if enabled), query string (if enabled), and/or cookies (if enabled). It will only serve a request from the cache if the request it would forward to the origin exactly matches one it sent in order to receive the response that it cached (and thus CloudFront can cache multiple variations of the same resource, based on the request parameters that you allow to be forwarded through). The reason for this is that a cache has an obligation not to make assumptions about how the server might vary the response based on different request parameters. Unless two requests are semantically equivalent, they can't be considered equivalent for caching purposes.

这篇关于AWS - Cloudfront - 如何使用Origin自定义标头的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！