Details
-
Bug
-
Resolution: Won't Fix
-
Neutral
-
None
-
6.2.26
-
None
-
-
Empty show more show less
-
X-Small
Description
Description
The X-Forwarded-Proto header is a de-facto standard header for identifying the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer. In deployments where a proxy (e.g. Fastly in PaaS) acts as TLS terminator with the clients but the proxy connects with Magnolia using http, Magnolia process the redirections using http. However, when Magnolia receives the X-Forwarded-Proto header, it should create the redirections using https, considering it received the X-Forwarded-Proto = https.
Steps to reproduce
- Create a rewrite rule (in Magnolia) to redirect /events.html into /about/events.html
- Access to http://localhost/events.html (with the correct port and context) with Postman (or curl) using http and sending X-Forwarded-Proto = https
- Magnolia returns a 301 response to http://localhost/about/events.html
Expected results
The redirection should be to https://localhost/about/events.html
Development notes
The class RequestDispatchUtil creates the new URL with this code:
if (isInternal(permanentUrl)) { if (isUsingStandardPort(request)) { permanentUrl = new URL( request.getScheme(), request.getServerName(), request.getContextPath() + permanentUrl).toExternalForm();
The problem is that request.getScheme() returns http, as the connection with Magnolia uses http. We should use the header X-Forwarded-Proto if it is set. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto
Reading about how Fastly behaves (https://docs.fastly.com/en/guides/tls-termination), it seems it uses a different header and different value for notifying that the client is using https, so it seems it is needed to either allow configuring the value of the header and the value that corresponds to https or maybe add different strategies and allow configuring one.