Does anyone have any information on shmcb cache sizings? Specifically, how
many bytes per request are taken up in shm for each cache entry? I'd like to
make sure my shm size is sufficient for the Cache Timeouts I want to use.
Secondly, is there any reason why the SSLSessionCacheTimeout can't
unless dared.
Secondly, is there any reason why the SSLSessionCacheTimeout can't be
arbitrarily large (say, an hour)? And at what size (or number of
entries) does the cache size begin to seriously hamper lookups within
the cache itself?
This was a problem with the earlier caching code (shmht
From: Geoff Thorpe [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 08, 2001 11:30 AM
To: '[EMAIL PROTECTED]'
Subject: RE: SSLSessionCacheTimeout
Hi there,
On Fri, 7 Sep 2001, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
Geoff,
Thanks for the detailed explaination
- or both. The timeout that I
was thinking of is some thing like
(10 * SSLSessionCacheTimeOut global_timeout 1500)
You can do this at an application specific basis. It does not hurt, as long
as you make sure that sessions will expire after some reasonable amount of
time. I cited from RFC 2246
(although I assume
per-process) time_t value that is stamped each time *real* expiry logic is
performed. All other expire attempts in future will silently return
without any action until SSLSessionCacheTimeout seconds have passed since
that time_t timestamp ... the first expire function call after
On Fri, Sep 07, 2001 at 09:52:42AM -0700, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
wrote:
If my understanding is correct, the current logic for
SSLSessionCacheTimeout (in mod_ssl) is to mark the time when the first
request was received, and then, irrespective of how long the connection
Lutz,
Thanks for that feedback.. When I meant reset the timeout, I certainly
did not mean to do it for ever.. There has to be a limit - either the number
of times the reset is done or the time limit - or both. The timeout that I
was thinking of is some thing like
(10 * SSLSessionCacheTimeOut
Hi there,
On Fri, 7 Sep 2001, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
If my understanding is correct, the current logic for
SSLSessionCacheTimeout (in mod_ssl) is to mark the time when the first
request was received, and then, irrespective of how long the connection has
been
The timeout on a session is also a concept subject to much
misunderstanding.
I've always though TTL, TimeToLive, was a better name.
/r$
--
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com
Lutz,
Thanks for that feedback.. When I meant reset the timeout, I certainly
did not mean to do it for ever.. There has to be a limit - either the number
of times the reset is done or the time limit - or both. The timeout that I
was thinking of is some thing like
(10 * SSLSessionCacheTimeOut
: SSLSessionCacheTimeout
Hi there,
On Fri, 7 Sep 2001, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
If my understanding is correct, the current logic for
SSLSessionCacheTimeout (in mod_ssl) is to mark the time when the first
request was received, and then, irrespective of how long the connection
Hi,
If my understanding is correct, the current logic for
SSLSessionCacheTimeout (in mod_ssl) is to mark the time when the first
request was received, and then, irrespective of how long the connection has
been active/inactive, remove the session identifier from the cache after the
timeout
12 matches
Mail list logo
