On Thu, Dec 04, 2008 at 12:13:52PM +0000, Dr Stephen Henson wrote: > At Joe's request I've posted the last comment here. It is in reference > to bug #43822 which is OCSP Stapling support for mod_ssl:
Thanks for posting. ... > The mutex code has been removed and some dummy functions to replace them > for now. I can change ssl_mutex_*() to apr_global_mutex_t and some > additional parameters for ssl_mutex_init() and ssl_mutex_reinit() and > removal of the special case code (AP_SOCACHE_FLAG_TOTMPSAFE etc) since > the mutex for stapling will always be used. I'm not sure whether it's worth abstracting the ssl_mutex code any further. Really all you need to do is call apr_global_mutex_* at the right times and log errors appropriately, as far as I can tell. > The timeout option doesn't currently work. There is support for timeout > in the generic-ish OCSP but it is hard coded. I could change that to > take a parameter. > > The uri and certificate parsing code does duplicate some used in some > static functions in the OCSP code (but with hard coded parameters). > Again that could be removed by some generalisation. That all sounds good. > I haven't at this stage altered the session caching code. It still makes > use of the SSL session cache to store OCSP responses. Would a separate > cache be in order, which works in a manner similar to the SSL session > cache? The requirements for the OCSP stapling cache differ from the > session cache: only a small number (one per certificate) of entries of > relatively small size (under 1K) will be needed but they are likely to > persist for longer (several minutes). Yup, I'd hope this is what the ap_socache.h interface makes simple: create a separate socache instance to cache the OCSP responses, so the dummy SSL_SESSION structures won't be needed. The "hints" interface lets the caller pass through the expected object size. Regards, Joe
