On Sun, 14 Dec 2025 11:39:12 GMT, EunHyunsu <[email protected]> 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
