[
https://issues.apache.org/jira/browse/HTTPCLIENT-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850527#comment-17850527
]
Zoe Wang commented on HTTPCLIENT-2328:
--------------------------------------
>Moreover, the server half-closing its endpoint while receiving a request
>message from the client would essentially be in violation of the HTTP spec.
I'm not saying sending data on a half-closed connection is a good practice; I
just don't see how it's violating HTTP spec. Also, half-closed connection has
been clarified in [https://github.com/httpwg/http-core/issues/22].
{quote}To avoid the TCP reset problem, servers typically close a connection in
stages. First, the server performs a half-close by closing only the write side
of the read/write connection. The server then continues to read from the
connection until it receives a corresponding close by the client, or until the
server is reasonably certain that its own TCP stack has received the client's
acknowledgement of the packet(s) containing the server's last response.
Finally, the server fully closes the connection.
It is unknown whether the reset problem is exclusive to TCP or might also be
found in other transport connection protocols.
Note that a TCP connection that is half-closed by the client does not delimit a
request message, nor does it imply that the client is no longer interested in a
response. In general, transport signals cannot be relied upon to signal edge
cases, since HTTP/1.1 is independent of transport.
{quote}
What I see here is inconsistent behavior between Apache sync client and async
client in the sense that connection received `close_notify` gets closed in
async but not in sync with TLS 1.3.
For anyone who stumbles across this issue, the root cause is that client does
not close the connection upon receiving `close_notify` anymore with TLS 1.3.
The workaround we tried that seems to be working is do a
"sock.getInputStream().read(new byte[0]);" before each write, which will check
`conContext.isInboundClosed()` and raise SocketException if inbound is closed.
> Request hangs if TLS 1.3 connection is half-closed
> ---------------------------------------------------
>
> Key: HTTPCLIENT-2328
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2328
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 4.5.14, 5.3.1
> Reporter: Zoe Wang
> Priority: Major
> Attachments: HalfCloseApache5Client.Java, HalfCloseServer.java,
> TlsHalfCloseApache4.java, keystore.jks
>
>
> If a server with TLS 1.3 support closes the connection during the request,
> more specifically, sending close_notify while the client is still writing to
> socket, the request will hang indefinitely. It's not an issue with TLS 1.2
> because it uses duplex-close policy. With TLS 1.3's half-closed connection
> policy, it seems Apache HTTP client is not able to detect connection closure
> properly. We are able to reproduce the issue with both 4.x and 5.x. I should
> note that HTTP URL connection does not have this issue.
> The workaround it to set `jdk.tls.acknowledgeCloseNotify` to true (see
> [https://bugs.openjdk.org/browse/JDK-8208526]), but that would require a lot
> of users to make changes on their side.
>
> Steps to repro:
> * Download the attached keystore file
> * Update ksPath in the server code HalfCloseServer.java to where you
> download the keystore
> * Run the server, the server will begin listening on {{localhost:8081}}
> * Create a random file of size 128MB and update client code "testFile" to
> where the file is.
> * Run the client, it should hang
> ** If System.setProperty("jdk.tls.acknowledgeCloseNotify", "true") is
> uncommented, it will not hang
> ** It also won’t hang if we we force TLS1.2
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
