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

[Julian Reschke]

On Tue, 11 Oct 2022 11:52:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> 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?
>
> Furthermore, on the HTTP/1.1 side, in the `Http1Request` class, there's a `hostString()` method which creates the value for the `Host` header field. In that method we have an additional check where we see if the port is unspecified (i.e. -1) and if it is, then we default the port to 443 for secure schemes or 80 for others, when creating the `Host` header value. I don't know why we do that though (couldn't find anything in spec which says we should be doing that). Should we be doing something similar here while constructing the authority header, to be consistent?

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


FWIW, RFC 7540 is now irrelevant; see https://www.rfc-editor.org/rfc/rfc9113.html instead

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

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