[
https://issues.apache.org/jira/browse/HTTPCLIENT-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850613#comment-17850613
]
Oleg Kalnichevski edited comment on HTTPCLIENT-2328 at 5/30/24 7:30 AM:
------------------------------------------------------------------------
> I just don't see how it's violating HTTP spec.
[~Zoe Wang] HTTP is defined as a *request / response* based protocol. HTTP
servers are expected to respond with a response message to a request message,
If the server does not want the client to continue sending content of the
request message body it must still respond with an out of sequence response
message and not just half-close connections in the middle of message exchange.
That is how.
> 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.
This is precisely what ResponseOutOfOrderStrategy does (which completely
decimates the i/o performance of the client, by the way). Feel free to use a
custom implementation or enhance the default one shipped with HttpClient.
Oleg
was (Author: olegk):
> I just don't see how it's violating HTTP spec.
[~Zoe Wang] HTTP is defined as a *request / response* based protocol. HTTP
servers are expected to respond with a response message to a request message,
If the server does not want the client to continue sending content of the
request message body it must still respond with an out of sequence response
message and not just half-close connections in the middle of message exchange.
That is how.
> 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.
This is precisely what ResponseOutOfOrderStrategy does. Feel free to use a
custom implementation or enhance the default one shipped with HttpClient.
Oleg
> 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
