ResteasyReactiveRequestContext getHttpHeaders and headers set by forwarded handling

[shawkins]

Describe the bug

When ResteasyReactiveRequestContext.getHttpHeaders is called will affect what headers are shown.

Expected behavior

Always get the headers after the host and possibly the trusted proxy header have been manipulated by the forwarded parser.

Actual behavior

A call to getHttpHeaders prior to some other call that will trigger the forwarded parser calculate method will cause the values of the headers pre forwarded parser handling to always be returned.

How to Reproduce?

Enable forwarded header processing.
Call getHttpHeaders before any logic that would trigger an underlying caculate.
Observer that the headers are unmodified.

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

cc @cescoffier - relates to the usability of 5069761

[geoand]

Can you please provide a sample application that shows what you are describing in action?

[quarkus-bot]

/cc @FroMage (rest)

[shawkins]

Can you please provide a sample application that shows what you are describing in action?

It's probably sufficient to just highlight the problematic code. getHttpHeaders creates/caches headers separate from the serverRequest

quarkus/independent-projects/resteasy-reactive/server/runtime/src/main/java/org/jboss/resteasy/reactive/server/core/ResteasyReactiveRequestContext.java

Line 234 in db7df2e

httpHeaders = new HttpHeadersImpl(serverRequest().getAllRequestHeaders());

A later manipulation of the headers, such as

quarkus/extensions/vertx-http/runtime/src/main/java/io/quarkus/vertx/http/runtime/ForwardedParser.java

Line 179 in db7df2e

delegate.headers().set(X_FORWARDED_TRUSTED_PROXY, Boolean.toString(isProxyAllowed));

will not show up in what is returned by an already cached ResteasyReactiveRequestContext.getHttpHeaders

[sberyozkin]

Look like Forwarded Vert.x handler is running after the REST request chain, the priority should be reversed, but I'm not sure where the fix should be done, also CC @cescoffier

[geoand]

I will have a look next week when I'm back