Support for an alternative header to X-Forwarded-Proto

Please add support for an alternative to the X-Forwarded-Proto header.

When Bloomreach HST is deployed behind an AWS Application Load Balancer (ALB), the X-Forwarded-Proto header is overridden to indicate the protocol of the request to the ALB. However, unless the browser is making connections directly to the ALB, the header value doesn't necessarily match the protocol that the browser used.

For example, in the following architecture, the value of X-Forwarded-Proto seen by Bloomreach will always be 'http', regardless of the protocol used for the request to the external ALB:

  External ALB (80/443) → nginx (80/443) → Internal ALB (8080) → Bloomreach HST (8080)

Another example of where a mismatch occur, is an architecture with a CDN that always uses https for requests to the origin, regardless of the protocol used by the browser.

The X-Forwarded-Proto header does not support comma-separated values in the same way that the X-Forwarded-For header does, and therefore cannot be used to access the protocol of the originating request from the browser.

Woonsan suggested creating a ticket to allow the value of X-Forwarded-Proto to be overridden by a new header, say X-BR-Forwarded-Proto, as the simplest way to resolve it.

An alternative solution might be to implement a configuration value where the name of the header to use can be provided. This would provide consistency with the Custom Resolution of Client's Originating IP Address feature, which is implemented in the same class (namely HstRequestUtils).