Intended behaviour of Forwarded Prefix header

[vmuzikar]

At Keycloak, we'd like to start using the Forwarded Prefix header (quarkus.http.proxy.enable-forwarded-prefix option), i.e. the X-Forwarded-Prefix header. But I'd like to discuss the intended behaviour of it in Quarkus as it doesn't seem correct to me.

The way I understand it, when the header is sent, it should be mostly transparent to the application. I.e. it should behave kinda like like the context root (quarkus.http.root-path option) but dynamic. However, that's not what I am seeing how it works.

Mapping using @Path seems to be reflecting the Prefix header in some cases. E.g. if send a request like:

curl .../bar -H "X-Forwarded-Prefix: /foo"

it will map to @Path("/foo/bar"), instead of @Path("/bar"). That seems rather unexpected. But it seems rather inconsistent as I am seeing this behaviour in my plain reproduced but not in Keycloak (not sure yet why, probably the same root cause as described here).

Second issue I'm seeing and that is blocking for Keycloak, is that the Prefix is not reflected in uriInfo.getBaseUri(). Again, there's a discrepancy with context root that is reflected there.

Is that really the intended behaviour? If not, I can create an Issue for that.

[sberyozkin]

Hi @vmuzikar

As far as the ForwardedParser is concerned, it looks like it is treating it correctly here.

My guess is that the reason you are seeing inconsistent results at the higher level in the REST (or Resteasy) code, is because, and this is just a theory, that since there could be a number of ways to get to the request URI or relative URI, some code is not seeing the updated relative path, bypassing the customized HTTP request prepared at the Forwarded headers processing time.

I'd say creating very specific issues (ex, UriInfo ignores X-Forwarded-Prefix, etc), ideally with reproducers against impacted extensions can help the team to find fixes, if you'd like please consider patches as well

Thanks