On 30.10.2014 15:51, Jeff Trawick wrote: > IMO the present concerns with OCSP Stapling are: > > * not so clear that it has seen enough real-world testing; commented out > sample configs and better documentation will help, as will enabling by > default in trunk (just a little?) > * related bugs 57121 and 57131 > > A simple way to help with the broader issue raised in 57131, as well as fix > 57121, is to not hold the global mutex while communicating with a > responder, with other handshakes completing with the existing response in > the cache as long as it is valid, or with the appropriate > communication-error response otherwise (some details omitted ;) ). > > There are a few other bugs currently open for less severe issues. > > TIA for your comments!
I'm -1 on this, under the assumption that 2.4.x would eventually also turn it on by default (yes, I'm aware of PR 50740, and CABF trying to push this). While enabling it by default on trunk probably doesn't change much (in my experience, very, very few people really compile and run trunk, I would even claim that this applies to http devs, too), I feel that the approach of "let's turn it on by default and see how many people run into problems" (and bring them up on httpd-users etc.) isn't right. Those interested in achieving a more widespread use should specifically test OCSP stapling with mod_ssl, report their findings, file PRs on Bugzilla (and if possible, also submit suitable patches). The fundamental objection I have to enabling stapling by default in our GA releases is that it would enable a "phoning home" feature (to the CA's OCSP responders) as a side effect of configuring a certificate. This is a setting I consider unacceptable for software published by the Apache HTTP Server project - the default must be opt-in, not opt-out. Kaspar
