httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dr Stephen Henson <shen...@oss-institute.org>
Subject Re: ocsp stapling global mutex
Date Wed, 14 Jul 2010 21:33:43 GMT
On 25/06/2010 08:10, Paul Querna wrote:
> Hi,
> 
> I was playing with OCSP Stapling in 2.3.6-alpha tonight, and I noticed
> that in the common case path, we will always lock a global mutex.
> 
> I don't see why this is needed for the cache hit case that uses
> non-SHM cache providers.
> 
> In fact, modssl_dispatch_ocsp_request, which is called on a cache
> miss, already has a serialize_request, so I'm not sure why there is a
> global mutex at all, even for cache updates.
> 
> It seems that inside stapling_mutex_{on,off} in ssl_util_stapling.c,
> the global mutex should only be used if (mc->stapling_cache->flags &
> AP_SOCACHE_FLAG_NOTMPSAFE) is true?
> 

The reason for this is to keep the number of OCSP queries to a minimum, which is
the main purpose of stapling.

If the cached response is acceptable the mutex will lock, retrieve and unlock
which should be handled relatively quickly.

In the case of an invalid (e.g. expired) or missing cached response an instance
locks, retrieves the cached response, realises it is invalid and then attempts
to retrieve and store an updated response from the responder and finally unlocks.

The update process could take a maybe a second or so. If the lock wasn't there
many instances on a heavily loaded server could query the responder almost
simultaneously.

Steve.
-- 
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org

Mime
View raw message