On Thu, 29 Sep 2022 09:09:59 GMT, Michael McMahon <micha...@openjdk.org> wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Describe oldClient
>
> src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line
> 442:
>
>> 440: // SSLSocket.close may block up to timeout. Make sure it's
>> short.
>> 441: serverSocket.setSoTimeout(1);
>> 442: } catch (Exception e) {}
>
> Is 1ms enough for a normal SSL close to complete? Does this mean that the
> normal close_notify exchange has to complete in that time?
full close takes one RTT, which may be much more than 1 ms. However, we are not
aiming for a full close here; [TLS
spec](https://datatracker.ietf.org/doc/html/rfc5246#section-7.2.1) says we
don't have to wait for the peer's close_notify after sending ours, and we don't
wait for it.
The wait is to make sure the OS sends our close_notify message, and does not
send a RST packet during that time if we happen to receive data from the peer.
1ms is definitely sufficient for HTTP 1, where the server should only send data
when requested.
-------------
PR: https://git.openjdk.org/jdk/pull/10401
