Sorry for the curtness. Thank you for replying. On mobile.
> On Jan 20, 2025, at 12:41 PM, Robert Engels 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 perfor
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 u
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 HTT
Hi all,
I don’t have the ability to create an OpenJDK issue.
Is this not the correct way to get this going? In the past, the net-dev has
been responsive to this sort of thing.
Maybe this was lost because it was sent over the weekend?
Thanks,
Robert
> On Jan 11, 2025, at 2:10 PM, robert engels
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
The problem is that the JDK HttpClient only supports upgrade attempts over
non-SSL, and has no su
