Encode IPV6 Zone IDs (%) in ReactorServerHttpRequest

[ls-urs-keller]

Affects: 6.0.7 (spring-web)

@Test
void test() {
	UriComponentsBuilder
		.fromUri(URI.create("http://[0:0:0:0:0:0:0:1%0]:8082/graphql"))
		.build(true);
}

Fails with

Invalid encoded sequence "%0]"

The code doesn't handle the ipv6 address zone id / scope id correctly.

[sbrannen]

Hi @ls-urs-keller,

Thanks for reporting the issue.

I converted your example to a test and have confirmed that it fails as you pointed out.

We will investigate our options.

Related Resources

• https://datatracker.ietf.org/doc/html/rfc3986
• https://datatracker.ietf.org/doc/html/rfc4007
• https://datatracker.ietf.org/doc/html/rfc6874

[ls-urs-keller]

@sbrannen Thank you for the quick reply.
This happens to us when doing calls on side cars in a multi-container k8s pod.
E.g. 1 pod with 2 containers, the container on port 8080 calls the container on port 8081 through localhost.
Using Spring graphql. We noticed the regression somewhere between spring boot 3.0.0 and 3.0.4, which probably relates to a netty update.

Our current workaround is to bind to the ipv4 loopback address through server.address: 127.0.0.1
But that only works for the specific case where there is only container-to-container traffic.

[poutsma]

RFC 6874, Section 2 shows us that

a zone identifier is attached to the textual representation of an IPv6 address by concatenating "%" followed by <zone_id>, where <zone_id> is a string identifying the zone of the address

and

any occurrences of literal "%" symbols in a URI MUST be percent-encoded and represented in the form "%25".

I believe URI.create should throw an IllegalArgumentException for http://[0:0:0:0:0:0:0:1%0]:8082/graphql, because the % has not been encoded to %25.

Passing true to UriComponentsBuilder::build indicates that the builder is in a fully encoded state. To ensure it is in a legal state, and that all parts of the URI have indeed been properly encoded, the UriComponentsBuilder performs an verification step, which throws the exception when it comes across the unencoded %.

Passing an encoded URI seems to work fine:

UriComponentsBuilder
    .fromUri(URI.create("http://[0:0:0:0:0:0:0:1%250]:8082/graphql"))
    .build(true);

as does passing false to build:

UriComponentsBuilder
    .fromUri(URI.create("http://[0:0:0:0:0:0:0:1%0]:8082/graphql"))
    .build(false); // or build()

@ls-urs-keller Where does the URI that triggers this behavior come from? Can you provide a stack trace? I am guessing it is from Reactor Netty, but I'd like to be sure. In any case, the code that creates that URI should be fixed to properly encode the %.

I also think that a bug should be reported to OpenJDK, as URI::create should throw an exception for that unencoded URI string.

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[sbrannen]

I also think that a bug should be reported to OpenJDK, as URI::create should throw an exception for that unencoded URI string.

This is a bit of a tricky topic.

Section 3, Web Browsers in RFC-6874 states the following (emphasis mine).

It is desirable for all browsers to recognise a ZoneID preceded by a percent-encoded "%". In the spirit of "be liberal with what you accept", we also suggest that URI parsers accept bare "%" signs when possible (i.e., a "%" not followed by two valid and meaningful hexadecimal characters).

Thus, it would appear that the JDK team took the same approach in java.net.URI, which is elaborated on in various parts of the code.

// Special case of server authority that represents an IPv6 address
// In this case, a % does not signify an escape sequence
private static final long L_SERVER_PERCENT

// 2) The only place where a percent can be followed by anything
// other than hexadecimal digits is in the authority component
// (for a IPv6 scope) and the whole authority component is case
// insensitive.
percentNormalizedComparison(String, String, boolean)

// Exception: any "%" found between "[]" is left alone. It is an IPv6 literal
//            with a scope_id
//
decode(String)

However, Section 3 of RFC-6874 goes on to say:

Such bare "%" signs are for user interface convenience, and need to be turned into properly encoded characters (where "%25" encodes "%") before the URI is used in any protocol or HTML document. However, URIs including a ZoneID have no meaning outside the originating node. It would therefore be highly desirable for a browser to remove the ZoneID from a URI before including that URI in an HTTP request.

So, I suppose it's a question of context.

In any case, I'm wondering if HierarchicalUriComponents.verifyUriComponent() should also be lenient in this regard when validating IPv6 addresses.

@rstoyanchev, @poutsma, @jhoeller: thoughts?

[poutsma]

I think you're right, I'll see what I can do about relaxing that check.

However, there's two parts to the Robustness principe, not just "be liberal with what you accept", but also "be conservative in what you produce". So you could argue that java.net.URL should escape the '%' when producing a string, even though it was not escaped when creating the URL.

@ls-urs-keller Even though we're going to fix this, I'd still like to know the source of that URI. If it is coming from Spring or Reactor, we should fix the code that produces the URI that as well.