Handle the path redirection in gateway

edevosc2c commented 7 months ago

Currently, at least in the docker composition of georchestra, it's traefik that handle the redirection when a final slash is missing for the component.

For example, to redirect from /geonetwork to /geonetwork/ so that geonetwork is actually served to the user when it goes to /geonetwork, not a 404 not found error page.

I'm proposing to implement this logic instead in the gateway. This way, it won't be needed anymore to have this logic inside the final webserver (traefik or NGINX or other).

The benefit are:

In Kubernetes (and docker compose), no more fixed hardcoded paths for the redirection.
The gateway knows much more than the final webserver which paths it is serving. If there is a need to redirect to a path with a final slash, then it can do it automatically. And do it also for any new path added to its config.
Redirect to a final slash out of the box, no need to configure anything anymore in the final webserver (traefik or NGINX or other).

I'm not sure what this represents in terms of work to do, nor if it's really feasible. But I'm very well sure that it would benefit the community as a whole, the redirect to a final slash that is not handled is the number one thing that it's always forget when deploying a new geOrchestra platform.

What do you think @groldan @pmauduit @fvanderbiest @jeanmi151 @jeanpommier @f-necas @danduk82

fvanderbiest commented 7 months ago

Sounds good to me, as long as it's generic enough (not hardcoded like it was in the security proxy)

pmauduit commented 7 months ago

I don't see any benefit to have it in the gateway more than in the frontend webserver configuration (okay, the front webserver could proxy to whatever service, regardless it is geOrchestra or another thing, but considering that we know that we are deploying a geOrchestra, why should it be agnostic to this point ?).

In any ways, it should already be possible to configure the gw accordingly, relying on the spring cloud gateway configuration: https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/

edevosc2c commented 7 months ago

we are deploying a geOrchestra, why should it be agnostic to this point ?

Because there are many ways to configure a webserver, traefik it's this way, nginx this way and so on. If we have this functionality built in the gateway, we wouldn't need to adapt the redirect based on the kind of webserver used. It would make our lives much easier.
One place, same way for everyone to configure the redirect.

Maybe we could introduce a parameter that can be enabled or disabled. If enabled, the gateway adds a final slash to the first path.

This way we do not interfere with the default behavior of gateway.

jeanpommier commented 7 months ago

I'd say it makes sense to put in geOrchestra as much as we can of the geOrchestra-specific logic, so +1 for me if there is a clean solution to implement it in the GW.

As @edevosc2c put it, it would be one less thing to worry about and possibly misconfigure on deployment.

edevosc2c commented 6 months ago

I found out that if you pass the correct host header to the final application (https://github.com/georchestra/georchestra-gateway/issues/102#issuecomment-1948010965). For example geonetwork if you pass the correct host header then geonetwork itself will gladly redirect you to the correct URL with the final slash.

On gateway without preserveHostHeader:

$ curl -I "https://mel.integration.XXX/geonetwork"
HTTP/2 302 
location: http://georchestra-geonetwork-svc:8080/geonetwork/

With preserveHostHeader:

$ curl -I "https://mel.integration.XXX/geonetwork"
HTTP/2 302 
location: http://mel.integration.XXX/geonetwork/

Now working on trying to tell the application that it needs to redirect to HTTPS. It's usually through the header X-Forwarded-Proto.

But at least we get a correct redirection from the app itself, not from the gateway!!!!

georchestra / georchestra-gateway

Handle the path redirection in gateway #94