JDK-8054022 : HttpURLConnection timeouts with Expect: 100-Continue and no chunking
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 7,8,11,17
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2012-08-21
  • Updated: 2024-02-23
  • Resolved: 2023-05-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 17 JDK 21 JDK 8
11.0.23Fixed 17.0.11Fixed 21 b22Fixed 8u391Fixed
Related Reports
Relates :  
JDK-8326549 - [11u] jtreg 6.1 not working for test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java
Relates :  
JDK-8326594 - Exclude test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java
Relates :  
JDK-8324209 - Check implementation of Expect: 100-continue in the java.net.http.HttpClient
Relates :  
JDK-8314164 - java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java fails intermittently in timeout
Relates :  
JDK-8326503 - [11u] java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java fail because of package org.junit.jupiter.api does not exist
Relates :  
JDK-8308336 - Test java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java failed: java.net.BindException: Address already in use
Description
FULL PRODUCT VERSION :
java version "1.7.0_04"
Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Linux rigi 3.4.7 #1 SMP Tue Aug 7 10:18:59 CEST 2012 x86_64 Intel(R) Xeon(R) CPU E31225 @ 3.10GHz GenuineIntel GNU/Linux

The Bug is OS independent

A DESCRIPTION OF THE PROBLEM :
It is cool that the JDK now  (after ~10 years of the first report) finally supports (and is therefore HTTP 1.1 conform) the expectation header. Really cool would it be if it would also work.

If chunking is disabled (the Http-Header contains a Content-Length field) and the Expect: 100-Continue header is set, the connection times-out on a POST request, because nothing is written to the wire and both endpoints awaiting input.

Simple testcases would prevent such bugs. And please test it also with a proxy, authentication and such before you mark this bug as fixed. I don't expect a fix in the next few years, but will not loose my hope...

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
- disable chunking
- enable Expectation
- Send a Post request

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
An answer from the server
ACTUAL -
Timeout

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.net.SocketTimeoutException: Read timed out

REPRODUCIBILITY :
This bug can be reproduced always.

<snip> - I've attached the testcase to bug report.
Comments
[jdk11u-fix-request] Approval Request from Anton Bobrov Re-submitting for approval since this needs to land before 2 missing test fixes so that they can be applied on top of it.
19-02-2024
Fix Request 11u Backport for parity with 11.0.22.0.1-oracle. The backport is done via existing 17u backport and applies cleanly. Included test and tier1 tests pass.
15-02-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2523 Date: 2024-02-15 08:50:45 +0000
15-02-2024
Fix request [17u] I backport this for parity with 17.0.9.0.3-oracle. Patch doesn't apply cleanly. The notable change is the call to HttpClient#parseHTTP due to a parameter mismatch. Testing: regression test passes and tier 1 passes with GHA.
12-12-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/2042 Date: 2023-12-11 19:23:12 +0000
12-12-2023
Changeset: 4b02956d Author: Darragh Clarke <darraghclarke98@gmail.com> Committer: Daniel Jeliński <djelinski@openjdk.org> Date: 2023-05-08 14:33:44 +0000 URL: https://git.openjdk.org/jdk/commit/4b02956d42c29ce32894f15411d3abe12b07dccd
08-05-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/13330 Date: 2023-04-04 17:02:08 +0000
04-04-2023
I can confirm the issue. Attached a modified reproducer that does not require any external code and can be run as a jtreg test. The problem is that if we set a streaming mode (either chunked or fixed length) and set ReadTimeout to a positive value, we wait for 100-Continue up to the configured ReadTimeout, and if we don't receive it, the request fails. If the mode is non-streaming, we start sending immediately. Any 100-Continue response is ignored. If the timeout is infinite, we wait for 100-Continue for up to (hardcoded) 5 seconds, then send the request body, then wait for the response using the original (infinite) timeout. Options? - We could always set the hardcoded 5-second timeout for receiving 100-Continue, then revert to the original read timeout - or we could set the timeout to a fraction of the configured ReadTimeout
06-12-2022