RFR: 8286171: HttpClient/2 : Expect:100-Continue blocks indefinitely when response is not 100 [v3]

Daniel Fuchs dfuchs at openjdk.java.net
Thu Jun 9 14:01:32 UTC 2022


On Thu, 9 Jun 2022 12:05:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Its not needed for a GET request as the client is not sending a body in that case. In this test the GET serves only to complete the HTTP/2 upgrade before testing with a POST request.
>
> From what I understand, the HTTP version in the client request comes in as an input to the test method and we pass `HTTP/1.1` as one such version. In that case there won't be a HTTP/2 upgrade involved since the request (via the client) will be pinned to HTTP/1.1 version. The test will still pass, but it won't be testing any `Expect: 100-continue` with `GET` requests. Of course GET requests aren't expected to have a request body, so testing this header with that method may not be meaningful after all (although the client implementation doesn't enforce that restriction).

The GET request is only needed when the input version is HTTP/2 - we don't want  to mix the upgrade with 100-continue. I am not sure how well our HTTP/2 server supports that. Our client would expect the server to first send 100-continue, and then do the upgrade after receiving the request body through HTTP/1.1. We don't support the other way round (101 followed by 100).
Here again maybe we should log a followup to try and verify what happens when both upgrade + 100 are specified - but for the moment I'll be satisfied if our client no longer blocks when receiving 417 (or any other code).

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

PR: https://git.openjdk.org/jdk/pull/9093


More information about the net-dev mailing list