Sorry for the curtness. Thank you for replying. On mobile.
> On Jan 20, 2025, at 12:41 PM, Robert Engels <reng...@ix.netcom.com> wrote: > > HTTPS incurs considerable overhead. The reason for prior knowledge http2 > connections is to be able to get the multiplexing features of http2 without > paying the https performance penalties. This is ideal for internal > api/application servers that are not exposed to the outside. > > I guess I don’t understand the reasoning - it is part of the rfc and part of > the original JEP that was accepted. Isn’t this simply a bug that needs to be > fixed - of which I am willing to do - but I need an accepted bug first. > >> On Jan 20, 2025, at 12:17 PM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: >> >> 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 >>
