Forward the Host header to the origin

[DmitriyKabanov]

On the application layer we need to access the Host header in the request object, however it's not equal to any of alternative domain names.

As of now, header behaviour is hardcoded as CacheHeaderBehavior.allowList('accept', 'accept-language', 'content-language', 'content-type', 'user-agent', 'authorization').

Adding host to this list breaks the API Gateway with 403 error, unless API Gateway is configured with custom domain names.

[sladg]

Yeah, ApiGw expects Host to be Cloudfront. We would need to do mapping of original Host to something like X-Host. I would need to take a look what is recommended way of doing this in AWS.

[DmitriyKabanov]

Any ETA on this?

[sladg]

@DmitriyKabanov I did a research and to support this properly, we would need to create Edge Lambda that would handle renaming headers and forwarding them.
It's quite unfortunate as I'm very much trying to stay away from Edge lambda due to limitations and deployment speed. I'm experimenting with keeping Edge lambdas same after first deploy.

No ETA yet, definitely bigger task than expected.

Any chance you could provide me with your usecase? Aka. what are you using Host for? Maybe I can suggest workaround in the meantime.

[DmitriyKabanov]

The use case is to build a redirectUrl to get back to the service.

[sladg]

That sounds like something that can be done by many different ways.
For example:

• if you are using API call, send hostname from client in request,
• if you are doing this in SSR, use relative route or pass environment variable to lambda (such as APP_URL=https://my.app.com
• if doing this on client, access it from window

[DmitriyKabanov]

For sure, it could be done by many different ways.
I'm not opposed to put a temporary workaround (as we already did).
I'm curious when this enchantment would be addressed?