AWS - Cloudfront - How To Use Origin Custom Headers

Question

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 He

Answer 1

How to access the headers that I set?

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

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.

Some potential applications:

• 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.

• 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

• 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.

• 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.