Server request URL with spring-webflux 6.0.5 is in resolved IP6 format

[Tomasz-Marciniak]

After upgrade to spring boot 3.0.3, Swagger authorization stopped working on http://localhost:8080.

The issue is caused by changed method:

private static URI resolveBaseUrl(HttpServerRequest request) throws URISyntaxException {
		String scheme = getScheme(request);

		InetSocketAddress hostAddress = request.hostAddress();
		...
}

From:

private static URI resolveBaseUrl(HttpServerRequest request) throws URISyntaxException {
		String scheme = getScheme(request);
		String header = request.requestHeaders().get(HttpHeaderNames.HOST);
		...
}

The root cause of issue is that instead of resolving host to http://localhost, it resolves http://[0:0:0:0:0:0:0:1].

The main functionality of swagger works with this IP address, but authorization fails because it redirects to:

To fix that issue I can set server.address, but then it breaks accessing swagger by external IP.

I found the issue after checking swagger, but rest of application works fine. Should openapi be fixed or resolveBaseUrl method?

Even enforcing IP4 by -Djava.net.preferIPv4Stack=true does not solve issue.

Downgrading to spring-web 6.0.4 solves the issue. Also using IP instead of DSN does not generate such issues.

[bclozel]

I think this is linked to #28601.

Transferring this issue to Spring Framework.

[Tomasz-Marciniak]

@bclozel - thanks for handling this.

[wilkinsona]

We suspect that spring-projects/spring-boot#34395 is another symptom of the same underlying problem.

[rstoyanchev]

Indeed, both this issue and spring-projects/spring-boot#34395 are linked to the change in #28601.

I tried the sample from spring-projects/spring-boot#34395, and the case there is an "X-Forwarded-Host" that contains both host and port (e.g. "localhost:3000"). When we parse the "Host" header ourselves, we handle this case. However, when relying on Reactor's request.hostAddress(), the hostString in it has the port and so the java.net.URI constructor fails with such a host. @violetagg, is there another Reactor request method we should use that takes care of this, or should we always parse the hostString we get from requst.hostAddress() just like we parse the "Host" header?

The case reported here is a little different. It looks like request.hostAddress() has a hostString that differs from what's in the "Host" header. I'm not clear on what to do with this one. It seems like the "Host" header has better information in this case, but if we use it first, then we're back to the issue with #28601. @violetagg any insight from your side would be appreciated. Ideally we would use a Reactor API, if available to obtain this information.

[bclozel]

See #30047 for a possible fix involving Netty's ˋNetUtil`.

[rstoyanchev]

#30047 looks more of an optimization that avoids an extra URI creation. I'm not sure it solves the issues here, but worth to consider at the same time.

[rstoyanchev]

As expected, Netty's NetUtil doesn't do anything for a hostString that has a port, so #30047 doesn't help for spring-projects/spring-boot#34395, and I suspect it doesn't help for this issue either, but I have no way to confirm that.

@Intosoft if you can provide an isolated sample to debug or verify changes with, that would be very helpful. Probably no need to see the authorization failures, but just enough to get such a server URL that differs between 6.0.4 and 6.0.5.

[violetagg]

"X-Forwarded-Host" that contains both host and port (e.g. "localhost:3000")

I think this is not a valid value

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Host

[Syntax]
X-Forwarded-Host: <host>

[Directives]
<host>
The domain name of the forwarded server.

[Examples]
X-Forwarded-Host: id42.example-cdn.com

[msosa]

But <host> according to them may optionally include a port

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host

The Host request header specifies the host and port number of the server to which the request is being sent.

I would think that X-Forwarded-Host would be closely related to just the Host header