In certain applications, it is crucial to be aware of the complete request URL, including the host, port, and scheme. These details are typically relayed via the headers X-Forwarded-Host, X-Forwarded-Port, and X-Forwarded-Proto. While Reproxy currently handles the X-Forwarded-Host header effectively, passing the original hostname, it does not accommodate for the port and scheme, which are essential in mixed protocol scenarios.

Use Case:
Our scenario involves deploying a Keycloak service with Reproxy. Internally, the Keycloak container exposes port 8080 and operates over HTTP. However, the public URL is configured as https://idp.example.com/, with Reproxy directing traffic to the Keycloak service. Keycloak is utilized for user authentication, with the frontend URL passing through Reproxy, while client authentication occurs directly via the container's hostname.

Observed Issue:
When attempting to access the Keycloak admin page, users are incorrectly redirected to http://idp.example.com:8080/. This behavior indicates a mismatch in the scheme and port handling between the internal service (Keycloak) and the external access method (Reproxy).

Posible Solutions:

• Automatic Header Handling: Implement functionality in Reproxy to automatically append X-Forwarded-Port: 443 and X-Forwarded-Proto: https headers when SSL is in use. This would ensure that services behind Reproxy are aware of the original request's protocol and port, even when the internal service operates over a different protocol or port.

• Custom Header Configuration: Introduce a new parameter in Reproxy's configuration to allow the addition of custom request headers. This would provide users with the flexibility to specify any necessary headers based on their unique deployment scenarios.