RFR: 8292876: Do not include the deprecated userinfo component of the URI in HTTP/2 headers [v5]

[Jaikiran Pai]

On Tue, 11 Oct 2022 11:31:37 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Changed the way the `:authority` pseudo header is set to only include host and, if available, port.
>> I added a test to cover this change that consists of a HttpClient that makes a request which contains userInfo, the test passes if the request is carried out with the userInfo not being added to the `:authority` header.
>> 
>> 
>> ### Tests
>> I ran Tier 1 - Tier 3 tests, as well as paying special attention to the http client tests to make sure they consistently passed
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed test

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 760:

> 758:             hdrs.setHeader(":authority", host + ":" + port);
> 759:         } else {
> 760:             hdrs.setHeader(":authority", host);

Hello Darragh, the RFC-7540 https://www.rfc-editor.org/rfc/rfc7540.html#section-8.1.2.3 states:


The ":authority" pseudo-header field includes the authority
portion of the target URI ([[RFC3986], Section 3.2](https://www.rfc-editor.org/rfc/rfc3986#section-3.2)).  The authority
MUST NOT include the deprecated "userinfo" subcomponent for "http"
or "https" schemed URIs.

So it has specific text about the scheme being "http" or "https". Should we add a check here to check the scheme, before creating this authority header with just the host:port?

I am unfamiliar with websocket (which the HttpClient API supports) which I think will have a different scheme, but a quick check suggests that for websockets, we probably won't reach this part of the code. So it probably is just a theoretical case that the scheme would be anything other than http or https. Perhaps we should just assert instead?

-------------

PR: https://git.openjdk.org/jdk/pull/10592