Connection timeouts in JEP 321 (HTTP Client)

[Simone Bordet]

Hi,

On Thu, Aug 2, 2018 at 10:44 AM Michael McMahon
<michael.x.mcmahon at oracle.com> wrote:
> On 31/07/2018, 22:07, Simone Bordet wrote:
> ..
> > Finally, I would consider TLS handshake time as part of the request
> > data: the cost will be paid by the first request and capped by "total"
> > timeout (not connectTimeout). With TLS 1.3 optimizations, it may be
> > just few TLS bytes before the encrypted request bytes. Thanks!
>
> On this point, why not time the handshake as part of the connect
> timeout? Then you would have consistency for all response times
> regardless of whether a new TLS connection is being set up, or an
> existing one reused. Granted TLS 1.3 improves this, but there is still
> overhead, and significantly more for new TLS sessions pre 1.3.

Having the TLS handshake as part of the connectTimeout is certainly fine.

I guess it'll just be more complicated from the implementation point
of view: if you consider TLS handshake as part of the "connect"
operation, then you will need to consider part of the "connect" also
the HTTP upgrade for WebSocket, and also the preface for HTTP/2, etc.

The "connect" operation to me is DNS+TCP, and it's typically easier to
design and code the "connect" separately from the layers that run
application protocols such as TLS, HTTP, etc. which may be combined in
various way.

Thanks!

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz