Hi Robert,
Sorry for the delay.
Prior knowledge has been on my mind for some time. I am however
unsure about whether there is an actual use case for the
HttpClient to support this.
With the deprecation of the HTTP/2 upgrade mechanism, there might
be. But are there actual deployment of clear HTTP/2 servers that
do not support the upgrade mechanism out there?
I would expect most deployments to redirect clear connections to
https these days (proxy connection excepted - but we don't support
clear HTTP/2 to proxies or over proxies).
Also there’s a question of what would happen if an HTTP/2 request
is sent to a server that doesn’t support HTTP/2. I guess such a server
would respond with 400 (Bad Request), and we’d also need to figure
out how the HttpClient should react (also given that a server that
actually support HTTP/2 might legitimately respond with 400 if
there something in the request it does not like).
I guess in this case we would simply relay 400 back to the caller
code - up to them to figure out that it meant their assumptions
were wrong.
So all in all I'm not sure there's a lot of appeal into supporting
prior knowledge for clear HTTP/2 connections.
best regards,
-- daniel
On 11/01/2025 20:10, robert engels wrote:
Hi,
According to RFC 9113 which obsoletes 7540, the Http2 upgrade mechanism
over non-SSL has been deprecated (for a variety of reasons). See
https://www.rfc-editor.org/rfc/rfc9113.html#section-3.1
<https://www.rfc-editor.org/rfc/rfc9113.html#section-3.1>
The problem is that the JDK HttpClient only supports upgrade attempts
over non-SSL, and has no support for “http2 using prior knowledge”. See
https://www.rfc-editor.org/rfc/rfc9113.html#section-3.3
<https://www.rfc-editor.org/rfc/rfc9113.html#section-3.3>
This is against JEP 110 https://openjdk.org/jeps/110
<https://openjdk.org/jeps/110> which forms the basis of HttpClient,
where it states:
*
Must be able to negotiate an upgrade from 1.1 to 2 (or not), or
select 2 from the start.
The latter half of this addresses the “http2 with prior knowledge”
portion of the specification. The current behavior is not compliant with
RFC 9113.
Are there plans to address this? Is there an outstanding bug I could
work on?
Thanks,
Robert Engels
