Re: Of HTTP-over-SSL/TLS connection persistence

As far as timeouts, my experience (as a server developer) is that clients will
typically treat the HTTP over SSL connections the same way they do insecure HTTP
connections, and use the same persistent connection timeout.

If you are talking about persistent connections of clients with HTTP over TLS
upgrade, then you just opened a can of worms :-) After either side times out that
persistent connection, the client would have to reconnect to the server and
"reupgrade" the connection to TLS ... Or maybe not, depending on what factors
trigger the TLS upgrade, - especially if it's triggered by the server on a part
of the URI space - so you might end up with a nonsecure connection after the
reconnect due to the timeout if the client reconnects with a different URI (there
could be other factors and other corresponding possible error cases ...). This is
one of the reasons I don't consider the current TLS upgrade draft very useful in
the real world; it seems to be only used for custom applications like IPP and I
don't think any major client supports it today. But my response probably goes
beyond what you were asking.

Jeff.Hodges@kingsmountain.com wrote:

> Ok, so now I'm postulating a server-side gizmo speaking "HTTP 1.0 |
> 1.1"-over-SSL/TLS that tries its best to have such connections be persistent.
>
> What do browsers typically do in ~this~ case -- how long before they'll
> timeout an idle connection if the user causes it to connect and then walks
> away for whatever reason?
>
> thanks,
>
> JeffH

--
The network is the computer, and it's down