ACCEPT header stripped off by Amplify before forwarding request to target server

[ssontakke]

Before opening, please confirm:

• I have checked to see if my question is addressed in the FAQ.
• I have searched for duplicate or closed issues.
• I have read the guide for submitting bug reports.
• I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

App Id

arn:aws:amplify:us-west-2:840725391265:apps/d2i6qlt8w44ey

Region

us-west-2

Amplify Console feature

Not applicable

Describe the bug

Context
We have a web application which has a functionality to download pdf, csv, xls, etc. Frontend hosted on Amplify and is a SPA. Frontend requests are routed to different external endpoints through Amplify Redirection/Rewrite Rules.

Here is what is happening:
Browser sends requests to Amplify hosted site - domain.com/some-unique-path to download a PDF. Request headers has ACCEPT = application/pdf.

Amplify has a redirection rule -

{
 "source": "/some-unique-path/<*>",
 "target": "https://subdomain.domain.com/<*>",
 "status": "200",
 "condition": null
}

On target server subdomain.domain.com, we are not receiving the ACCEPT header. We also noticed that CONTENT_TYPE, HTTP_ACCEPT headers are also empty on the target server.

Expected behavior

Amplify redirection shouldn't modify any headers. On the target server, we should get ACCEPT headers as it was passed by browser.

Reproduction steps

1. Create a 200 redirection rule in Amplify like this:

{
 "source": "/some-unique-path/<*>",
 "target": "https://subdomain.domain.com/<*>",
 "status": "200",
 "condition": null
}

2. Do a curl call to Amplify hosted site and set ACCEPT = 'application/pdf'
3. Observe the headers received on target server. You will see ACCEPT header is stripped off.

Build Settings

No response

Additional information

No response

[github-actions]

Hi 👋, thanks for opening! While we look into this...

If this issue is related to custom domains, be sure to check the custom domains troubleshooting guide to see if that helps. Also, there is a more general troubleshooting FAQ that may be helpful for other questions.

Lastly, please make sure you've specified the App ID and Region in the issue!

[victorccccc]

Hi, unfortunately, we don't support forwarding these headers to your target server (reverse proxy) from Amplify managed distribution. According to https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#request-custom-headers-behavior, Cloudfront removes some request headers while processing the request.

So, I'll mark this as a feature request. Thanks.

[Rafcin]

#8446 Somewhat related to this, when deploying a Next app, hosting won't allow me to use the cloudfront geolocation headers. Setting them manually in cloudfront won't work and they end up being overwritten by each build. I think Amplify should add a configuration option for cloudfront to allow us to use the service to the fullest potential. I have an app that relies on a users location, for me it would be cheaper to use the cloudfront headers rather than have to set up my own geoip service and resolve a location based on the uses IP. It would hurt my wallet less as well.

[fnavarrodev]

What's the status of this request?

[jmcpeak]

I need the referrer header in my next 13 app - how can I get it?

[yahya-evoly]

I need the referrer header in my next 13 app - how can I get it?

I reached out to AWS technical support regarding this issue recently. Unfortunately, they confirmed there's no direct solution at the moment. If anyone has discovered a workaround, I'd be keen to hear about it!

[jmcpeak]

Thanks for the response @yahya-evoly.

The AWS link @victorccccc gave for headers that are passed was very helpful.

[calavera]

This feature has just been supported with our latest launch! I'm closing this issue as it's been resolved.

Check out the details here: https://aws.amazon.com/blogs/mobile/cdn-caching-improvements-for-better-app-performance-with-aws-amplify-hosting/

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.

[github-actions]

This issue has been automatically locked.