RFR: 8371903: HttpClient: improve handling of HTTP/2 GOAWAY frames with error code [v7]

[Daniel Fuchs]

On Mon, 15 Dec 2025 14:26:31 GMT, Christoph Läubrich <duke at openjdk.org> wrote:

>> Hello Christoph,
>> 
>>> I think this test assertion alone already shows that a client has only the chance to use String parsing what I think is bad (both for test and for production code).
>> 
>> The API specification of HttpClient for send/sendAsync currently only specify IOException with no specific expectations of HTTP protocol specific exception types. In several areas of the JDK tests, when necessary, we do check the exception messages to be sure that we are testing the right failure/exception. Of course, any changes to those internal exception messages would require updates to related tests.
>> 
>>> If its not planned to have an own public type, can it at least be an internal exception type that can be used in the test?
>> Maybe a Http2ProtocolError?
>> 
>> Your suggestion is valid one . Like Daniel has noted, we do have plans to propagate certain HTTP protocol specific error details to the application from the HttpClient send/sendAsync APIs, and I think we see the value in doing that. It will require specification updates (which is fine) and will require some more thoughts on how we want to do it. For example GOAWAY is specific to HTTP/2 and HTTP/3 whereas the HttpClient supports HTTP/1.1 too. So it will require some thoughts on how we specify such exceptions for these APIs.
>> 
>> I will check our JDK issue tracker to see if we have already filed an issue for this and if not, I'll file an enhancement and link it here.
>
>> The API specification of HttpClient for send/sendAsync currently only specify IOException with no specific expectations of HTTP protocol specific exception types
> 
> Even though its nice do document all possible subtypes I think its not specifically forbidden (or can be enforced) and there is at least on precedence with `HttpTimeoutException` (and I can think of many more e.g EOFException in general) and `jdk.internal.net.http.common.Utils.toConnectException(Throwable)` even checks for some of those already (and I see none of those explicitly documented).
> 
> So I think it not necessarily requires a specification change, for a first step it could even be non public internal types like `jdk.internal.net.http.common.ConnectionExpiredException`.

Even though there may be some precedents, Internal exception types should not be relayed to user code. In addition introducing new public exception types also introduce new serializable APIs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28632#discussion_r2619953365