Why CloudFront removes and/or doesn't add the X-Forwarded-Proto header?
I am currently setting up a tusd (tus.io) server behind a CloudFront distribution, and in order for tusd to operate behind a proxy, it needs the X-Forwarded-Host and X-Forwarded-Proto headers. See reference [1].
While trying to add the headers to the CloudFront distribution, I see that all the headers I've added are sent to the origin, except for the X-Forwarded-Proto header. See log message from the origin:
..., 'X-Forwarded-For': ['<Some IP address>'], 'X-Forwarded-Port': ['443'], 'X-Forwarded-Ssl': ['on']
You can see the headers I added to CloudFront in the attached screenshot.
As per the AWS documentation [2], CloudFront removes the X-Forwarded-Proto, but what is the reason?
[1] - https://github.com/tus/tusd/blob/main/docs/faq.md#can-i-run-tusd-behind-a-reverse-proxy [2] - https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestBehaviorCustomOrigin
- Newest
- Most votes
- Most comments
Try leveraging the CloudFront Origin Request Policies https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-origin-requests.html to control what CloudFront is sending to the origin.
One needs to allow list many common headers like XFP which is outlined in the guide for custom origin headers handling. Often I advise customers leverage the managed policy "All viewer headers" in context to custom origins, as this managed policy sends all the headers we got from the edge to the origin, including host. Note that the Origin Request Policies do not affect the cache key as caching is defined in the Cache Policy.
For reference, I ended up setting a reverse proxy that adds the X-Forwarded-Proto.
See: https://github.com/nginx-proxy/nginx-proxy/tree/main/docs
Relevant content
- asked a year ago
- asked 3 months ago
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
One peculiar thing about CloudFront is that by default it minimizes what is forwarded to the origin. As the docs say: "Other information from the viewer request, such as URL query strings, HTTP headers, and cookies, is not included in the origin request by default.". Thus as AWS-amo noticed use an Origin Request Policy that fits your use-case.
Many thanks for your reply @AWS-amo ! I'm already using the
AllViewermanaged policy, but what is needed in this case is for CF to add the header (it's not sent as part of the client request). Does it make sense?Yes @redouane your inquiry makes sense - I was just experimenting with XFP and it seems to be a sensitive header (for what rationale escapes me atm). Is there anyway you could perhaps leverage CloudFront-Forwarded-Proto – Contains the protocol of the viewer's request (HTTP or HTTPS). Still this header would need to be allowed in the Origin Request Policy.
Thanks @AWS-amo - it's possible to use CloudFront-Forwarded-Proto on the origin with some modification to the opensource code. Also another option is to set a reverse proxy that will only take care of adding the custom headers, but maybe that's an overkill.