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

[Daniel Fuchs]

On Tue, 11 Oct 2022 12:34:10 GMT, Julian Reschke <duke at openjdk.org> wrote:

>> 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

>  Should we be doing something similar here while constructing the authority header, to be consistent?

Well https://www.rfc-editor.org/rfc/rfc9113.html#name-simple-request has an example where authority doesn't have the port - so I don't think we need to add it. FWIW the HTTP/1.1 code seems to be *removing* the port when it's the default one. Probably for normalization of the host string?

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

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