(aws-cloudfront-origins): add custom headers to S3Origin

[robertd]

Based on the conversation in #10829, it'd be nice to be able to add custom headers to S3Origin.

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html

cc @nwitte-rocketloans

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[njlynch]

Can someone enlighten me on the use-case for passing the custom headers to an S3 origin? What are examples of headers passed to S3 that have an impact on how the content is served and/or logged? The official documentation even note that the headers won't be logged ("If you’re using an Amazon S3 origin and you enable Amazon S3 server access logging, the logs don’t include header information.").

The linked PR (#16161) looks fine, and I won't block it for long, but I'd like to understand a bit more deeply about why someone wants to do this before we commit to it in the API.

[robertd]

@njlynch I'll have to delegate this to @nwitte-rocketloans for an example where this would be useful.

Frankly, we have 50+ CF distros using S3Origin in production and we serve all kinds of apps (React, Vue, Angular, etc). However, I haven't yet received a request from our developers for this functionality (keyword: yet)... but there must be a use case out there.

[nwitte-rocketloans]

Can someone enlighten me on the use-case for passing the custom headers to an S3 origin? What are examples of headers passed to S3 that have an impact on how the content is served and/or logged? The official documentation even note that the headers won't be logged ("If you’re using an Amazon S3 origin and you enable Amazon S3 server access logging, the logs don’t include header information.").

The linked PR (#16161) looks fine, and I won't block it for long, but I'd like to understand a bit more deeply about why someone wants to do this before we commit to it in the API.

Lambda@Edge does not support environment variables. Using S3 Origin Custom Headers, environment variables can be passed into a Lambda@Edge script explicitly, and captured in the event object on the origin request and origin response. The last I read about it, this was AWS's best practice for passing dynamic values into a Lambda@Edge script.

[birtles]

Can someone enlighten me on the use-case for passing the custom headers to an S3 origin? What are examples of headers passed to S3 that have an impact on how the content is served and/or logged? The official documentation even note that the headers won't be logged ("If you’re using an Amazon S3 origin and you enable Amazon S3 server access logging, the logs don’t include header information.").

In the past I needed this to override the Origin header passed to S3. As I recall, the header needs to be passed along for CORS requests (otherwise we'll cache a response without Access-Control-Allow-Origin) but Firefox Web Extensions produce a different origin for each installation and so passing this on as-is would produce poor cache performance.

Details below:

• https://twitter.com/brianskold/status/1200351837980749826
• https://serverfault.com/questions/619699/setting-access-control-allow-origin-on-cloudfront/912489#912489

But perhaps there is another way to work around this since the introduction of cache and origin request policies?

[njlynch]

@nwitte-rocketloans: Lambda@Edge does not support environment variables. Using S3 Origin Custom Headers, environment variables can be passed into a Lambda@Edge script explicitly, and captured in the event object on the origin request and origin response.

Ah, this makes sense (sort of). I can imagine other ways to go about it, but it's certainly one of the simpler ones. This is the use case I needed to make this feature make sense. :) The headers aren't really going to S3, they're going to a Lambda@Edge origin event. 👍 Thanks!

@birtles: As I recall, the header needs to be passed along for CORS requests. [...] But perhaps there is another way to work around this since the introduction of cache and origin request policies?

The built-in way to do CORS for S3 buckets is OriginRequestPolicy.CORS_S3_ORIGIN.

new cloudfront.Distribution(stack, 'Distribution', {
  defaultBehavior: {
    origin: new origins.S3Origin(bucket),
    originRequestPolicy: cloudfront.OriginRequestPolicy.CORS_S3_ORIGIN,
  },
});

The above will ensure that the Origin, Access-Control-Request-Headers, and Access-Control-Request-Method headers are sent to the origin (S3). However, it sounds like for your case of wanting all multiple origins to be effectively treated as one, custom headers might be way to go still.

Thanks all!

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.