Http2, HttpClient, and RFC 9113

[Robert Engels]

Sorry for the curtness. Thank you for replying. On mobile. 

> On Jan 20, 2025, at 12:41 PM, Robert Engels <rengels at 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.fuchs at 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
>>