Prevent encoding of [] in the host part of IPv6 reference URIs

[FelixMartel]

Currently proxying IPv6 reference URIs is not possible #3705. This is because HttpRequestHeader.parseURI first attempts to repair URIs containing unencoded characters by encoding them before calling new URI with encoded=true. Otherwise new URI would throw a URIException. This includes the [] characters that are part of the IPv6 reference section and so new URI(http://[::1]/) becomes new URI(http://%5B::1%5C).

Here I want to avoid having to add parsing of the authority section to HttpRequestHeader while keeping the URI repairing behavior the same. Only calling new URI with encoded=false gives a different result (for example % becomes %25) and so it is only used to detect IPv6 reference URIs and parse out the host:

• First call new URI with encoded=false.
• If this was an IPv6 reference then apply repairing to the rest of URI.
• Otherwise repair the whole URI.
• Finally call new URI with encoded=true.

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[thc202]

Better accept the CLA before continuing with more work, without that the changes will not be merged.

[thc202]

This will require tests (a lot of them).

[FelixMartel]

I have read the CLA Document and I hereby sign the CLA

[kingthorin]

Could use List.of

[kingthorin]

Or even Stream.of I think, should be other examples in the repo

[kingthorin]

Seems to have broken binary compatability

[kingthorin]

Does <username>:<password>@<host> parse as expected if password has square brackets?

[FelixMartel]

Looks like it behaves the same as it does now when given asdf:[]@example.com. In practice I don't think clients supply credentials there.

[kingthorin]

They "shouldn't", but it's 'allowed' by spec and browsers so it'd be good to add a test just to ensure that nothing breaks in the future, for my two cents.