Why does APIGW HTTP API use Forwarded header, while other services still use X-Forwarded headers?

I have been trying to set up a straightforward API stack, consisting of a Fargate service (running a container hosting a Node Express server) with a private, HTTP Application Load Balancer (ALB), VPCLink and API Gateway (APIGW). Ultimately we'll want to set up route53 and use a public, https ALB; however, this APIGW-fronted stack will be really useful for testing and development.

The APIGW needs to be the newer HTTP API so that it can integrate with ALB. But HTTP API (as opposed to REST API) adds the Forwarded header to indicate it is proxying requests, whereas ALB adds the X-Forwarded- headers, so the request that arrives at my Express server has both. My server cannot know the order of these proxies, but in any case, proxy trust capability in Express only reads the X-Forwarded- headers, so my server sees the request as insecure (as ALB adds X-Forwarded-Proto: http).

The upshot of all this is that I am unable to send secure session cookies between server and browser, which is a showstopper.

I understand that I could stand up a Network Load Balancer in between APIGW and ALB, but that seems like overkill when APIGW's HTTP API is by design able to directly integrate with ALB. Can we not have a config setting to determine which headers to use? Or better still, can HTTP API not determine which headers to use based on the integration type?

Update

I've since tried with NLB in between Gateway and ALB, using REST API to integrate with the NLB, but that is even worse because REST API does not seem to attach either set of headers to identify the (cloudfronted, secure) client, and provides no mechanism to add these ourselves. At least we get the correct Forwarded headers with HTTP API.