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

[Jaikiran Pai]

On Sun, 14 Dec 2025 11:39:12 GMT, EunHyunsu <duke at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/http2/GoAwayWithErrorTest.java line 162:
>> 
>>> 160:                         && goawayError.getMessage().contains("0x1")
>>> 161:                         && goawayError.getMessage().contains(DEBUG_MESSAGE),
>>> 162:                 "Failed request should contain GOAWAY error details: " + goawayError.getMessage());
>> 
>> 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).
>> 
>> 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?
>
> @laeubi I appreciate your suggestion about semantic error handling. I looked into how HTTP/3 handles similar cases for consistency.
> 
> HTTP/3 tests also use string parsing to verify error messages. For example, in `test/jdk/java/net/httpclient/http3/H3ErrorHandlingTest.java:954-955`:
> 
> 
> assertTrue(cause.getMessage().contains(reason),
>         cause.getMessage() + " does not contain " + reason);
> 
> This pattern is used throughout HTTP/3 tests (e.g., verifying "INTERNAL_ERROR", "CRYPTO_ERROR", "H3_EXCESSIVE_LOAD" in error messages).
> 
> As @djelinski mentioned, this PR brings HTTP/2 error handling to parity with HTTP/3's current approach. I agree that a specialized exception type would be valuable, but it would ideally be done consistently across both HTTP/2 and HTTP/3 as a future enhancement.

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.

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

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