JDK-8218546 : Unable to connect to https://google.com using java.net.HttpClient
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 11.0.14,12,13
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-02-06
  • Updated: 2022-03-30
  • Resolved: 2019-02-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12 JDK 13
11.0.14.1Fixed 12 b32Fixed 13Fixed
Related Reports
Blocks :  
JDK-8211308 - Support HTTP/2 in WebView
Duplicate :  
JDK-8280685 - http2 client improperly adds Host header to requests in jdk11 update
Duplicate :  
JDK-8280695 - Received RST_STREAM when connecting to https://google.com on HTTP/2
Duplicate :  
JDK-8218623 - HttpClient throws "RST_STREAM: Protocol error" when Http2 is not supported
Relates :  
JDK-8280685 - http2 client improperly adds Host header to requests in jdk11 update
Relates :  
JDK-8213189 - Make restricted headers in HTTP Client configurable and remove Date by default
Description
The attached test connects to https://google.com through HTTP/2.0 and it received the following exception,

java.util.concurrent.ExecutionException: java.io.IOException: Received RST_STREAM: Protocol error

It used to work until JDK-12+19.
Comments
Hi, Thanks for fixing this also in 11.0.14.1. For completeness I want to add: the same problem happens not only with Google's web server. Also recent nginx versions produce same result. They return error 400 and inside the server log you can find the message about "duplicate host header". It is not really duplicate, but nginx seem to treat "host" and ":authority" the same way.
30-03-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk11u/pull/26 Date: 2022-02-07 10:49:00 +0000
07-02-2022
Critical Fix request (11u) We want to bring this to jdk11u; 11.0.14.1 see http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2022-February/011862.html Applies clean.
07-02-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk11u-dev/pull/798 Date: 2022-01-27 09:16:03 +0000
27-01-2022
Fix Request (11u) Fixes a major regression after JDK-8213189 backport. Applies cleanly. Testing passes.
27-01-2022
Verified on jdk-12+32 build, regression test and attached sample passed. As comparison, they are failed on previous b31 build.
15-02-2019
Fix request approved Important and low risk fix.
08-02-2019
Fix Request It is important to fix this bug because: 1) it impacts interoperability with some popular HTTP/2 servers, and 2) it is a regression in behaviour from the previous release, JDK 11. The fix simply reverts the specific code that sets the `Host` header for new HTTP/2 streams, to that of what it was in JDK 11. The risk is considered very low since the code changes are small, localized, and well understood. All HTTP Client, Networking, and tier1-tier2-tier3 tests have been run successfully. The fix has been reviewed by @fduchs. RFR https://mail.openjdk.java.net/pipermail/net-dev/2019-February/012175.html Webrev http://cr.openjdk.java.net/~chegar/8218546/webrev.01/
08-02-2019
URL: http://hg.openjdk.java.net/jdk/jdk12/rev/68ca8b201925 User: chegar Date: 2019-02-08 12:35:11 +0000
08-02-2019
Post JDK-8213189 the HTTP Client now adds both the `:authority:` pseudo-header and the `Host` header to outbound HTTP/2 requests. The HTTP/2 RFC does not seem to rule out this behavior, but it does recommend that the pseudo-header be used instead of the `Host` header. Section 8.1.2.3. Request Pseudo-Header Fields ... Clients that generate HTTP/2 requests directly SHOULD use the ":authority" pseudo-header field instead of the Host header field. ... I'm not quite sure why the Goog server rejects such a request ( with both headers ). Other HTTP/2 servers that I have checked do not.
07-02-2019
While the behaviour of the Goog server is questionable, the fact remains that the HTTP Client cannot successfully interact with it over HTTP/2. The behaviour of the client, post JDK-8213189, has deviated away from what is recommended by the RFC. On balance, it seems safest to just revert the small part of the change for JDK-8213189 that caused this issue. The small part is not even all that relevant to the crux of the fix for JDK-8213189.
07-02-2019
Running the test with header logging enabled we see a 400 response code from the server. java -Djdk.httpclient.HttpClient.log=headers Http20GoogleTest Feb 06, 2019 12:14:02 P.M. jdk.internal.net.http.Http2Connection encodeHeaders INFO: HEADERS: HEADERS FRAME (stream=1) :authority: www.google.com :method: GET :path: / :scheme: https host: www.google.com User-Agent: Java-http-client/13-internal Feb 06, 2019 12:14:02 P.M. jdk.internal.net.http.Stream handleResponse INFO: HEADERS: RESPONSE HEADERS: :status: 400 content-length: 1555 content-type: text/html; charset=UTF-8 date: Wed, 06 Feb 2019 12:11:49 GMT referrer-policy: no-referrer Exception in thread "main" java.util.concurrent.ExecutionException: java.io.IOException: Received RST_STREAM: Protocol error ....
06-02-2019