RFR: 8292044: HttpClient doesn't handle 102 or 103 properly [v4]

[Julian Reschke]

On Fri, 9 Sep 2022 07:06:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8292044?
>> 
>> The linked JBS issue notes two parts to fixing this. Part one is to (internally) ignore the intermediate 1xx informational responses, in the client and wait for subsequent final response from the server. Part two is to introduce newer APIs to let applications using HttpClient, to have access to these intermediate response (codes). This commit (only) addresses part one. Part two is out of scope of this change and a separate issue will be opened to address it (at a later time).
>> 
>> The commit in this PR introduces a check to see if the returned response is an informational response (as defined by RFC-2616 https://www.rfc-editor.org/rfc/rfc2616#page-58). If the response code is between 102 and 199 (inclusive), then this change ignores that response and keeps waiting for a subsequent final response from the server.
>> 
>> The request timeout (if set) will _not_ be reset when a intermediate informational response is received (and we ignore it). The request timeout handling continues to be the same as what it is currently and will span from the request start till the final response is received. If no final response is received within the duration of request timeout (if set) then the application will continue to receive a request timeout exception.
>> 
>> A new test class has been introduced to reproduce the issue and test the fix. The test tests both HTTP/1.1 and HTTP2. 
>> 
>> tier1, tier2 and tier3 testing is in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ignore 100 response when request isn't configured for expect continue

Left a few comments regarding which RFCs are relevant.

src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 503:

> 501:         // we ignore any response code which is 1xx.
> 502:         // For 100 (with the request configured to expect-continue) and 101, we handle it
> 503:         // specifically as defined in the RFC-2616 (HTTP 1.1 spec), outside of this method.

RFC 2616 is irrelevant. You need to look at RFC 9110 and 9112.

src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 504:

> 502:         // For 100 (with the request configured to expect-continue) and 101, we handle it
> 503:         // specifically as defined in the RFC-2616 (HTTP 1.1 spec), outside of this method.
> 504:         // As noted in RFC-7231, section 6.2.1, if response code is 100 and if the request wasn't

So is RFC 7231.

src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 508:

> 506:         // response (just like any other 1xx response)
> 507:         // Any other response code between 102 and 199 (both inclusive) aren't specified in the
> 508:         // HTTP 1.1 spec. The spec states that these 1xx response codes are informational and

This is not specific for version 1.1 of HTTP. See RFC 9110.

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

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