On Fri, 9 Sep 2022 07:06:32 GMT, Jaikiran Pai <[email protected]> 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
