Bug report for Apache httpd-2 [2015/05/03]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 7483|Ass|Enh|2002-03-26|Add FileAction directive to assign a cgi interpret| | 8713|Inf|Min|2002-05-01|No Errorlog on PROPFIND/Depth:Infinity| | 8867|Opn|Cri|2002-05-07|exports.c generation fails when using a symlink to| |10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i| |11294|New|Enh|2002-07-30|desired vhost_alias option| |11580|Opn|Enh|2002-08-09|generate Content-Location headers | |12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long| |12680|New|Enh|2002-09-16|Digest authentication with integrity protection | |13599|Inf|Nor|2002-10-14|autoindex formating broken for multibyte sequences| |13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation | |14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR| |14496|New|Enh|2002-11-13|Cannot upgrade any version on Windows. Must uninst| |14922|Inf|Enh|2002-11-28|target is currently hardcoded to 'apache2' | |15719|Inf|Nor|2002-12-30|WebDAV MOVE to destination URI which is content-ne| |16761|Inf|Nor|2003-02-04|CustomLog with pipe spawns process during config | |16802|New|Enh|2003-02-05|Additional AllowOverride directive Restrict | |16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.| |17107|New|Min|2003-02-16|Windows should not install printenv | |17114|New|Enh|2003-02-17|Please add strip and install-strip targets to Make| |17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi| |17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header| |18325|New|Enh|2003-03-25|PAM support for suEXEC| |18334|Inf|Cri|2003-03-25|Server crashes when authenticating users against L| |18497|New|Min|2003-03-30|configure --help gives wrong default for sysconfdi| |19043|New|Min|2003-04-15|Interesting interaction between cern_meta module a| |19670|New|Enh|2003-05-05|content type header supplied upon PUT is thrown aw| |20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment | |21253|New|Nor|2003-07-01|Mime magic doesn't continue if type is specifed fo| |21260|New|Nor|2003-07-02|CacheMaxExpire directive not enforced ! | |21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut| |22138|Inf|Cri|2003-08-05|Webdav is not preccessing special chars right.| |22237|New|Enh|2003-08-08|option to disable ServerSignature on index pages | |22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down| |22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7| |22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header | |23167|Inf|Cri|2003-09-14|--enable-layout never goes to apr apr-util| |23181|New|Nor|2003-09-15|Status 304 (Not modified) and chunking leads to an| |23238|New|Cri|2003-09-18|non-async-signal-safe operations from signal handl| |23330|New|Enh|2003-09-22|Enhance ApacheMonitor to view and control Tomcat s| |23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54| |24031|New|Enh|2003-10-23|Passphrase protected private key in SSLProxyMachin| |24095|Opn|Cri|2003-10-24|ERROR Parent: child process exited with status 32| |24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g| |25014|New|Enh|2003-11-26|A flexible interface for mod_log_config | |25201|New|Enh|2003-12-04|Provide Cache Purge operation | |25240|Inf|Enh|2003-12-05|SSL Library Error: 336105671 logged as information| |25435|New|Enh|2003-12-11|sethandler and directoryindex not playing nice| |25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files | |25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP | |25543|Inf|Nor|2003-12-15|mod_proxy_ajp overwrites existing response headers| |25667|New|Nor|2003-12-19|Memory leak in function ssl_scache_dbm_retrieve().|
Solving mutex concerns with OCSP stapling
Your thoughts on the following? Current OCSP behavior that I think needs to be fixed: mod_ssl holds the single stapling global mutex when looking up a cached entry, deserializing it, checking validity, and (when missing/expired) communicating with the OCSP responder to get a new response. 1. mod_ssl shouldn't hold the single stapling global mutex when talking to the OCSP responder. This will stall ALL initial handshakes in all stapling- enabled vhosts, regardless of the certificate they use. 2. For the cache itself, mod_ssl shouldn't hold the single stapling global mutex when looking up a cached entry unless the socache type requires it for its own purposes. (memcached and distcache do not require it.) Assumption: The cache can be shared among different httpd instances (e.g., via memcached) but getting different instances to agree on which instance refreshes the cache is not worth handling for now. (Let multiple instances refresh if the timing is unlucky.) What must be serialized globally within an httpd instance? 1. If the socache provider requires it: Any access to the stapling cache. 2. A thread claiming responsibility for refreshing the cached entry. Why no global mutex per certificate? 1. There could be a large number of certificates, and lots of global mutexes could be very surprising or even require OS tuning with some mutex types. 2. A single mutex is required to interact with the cache anyway (when the cache requires a mutex). 3. That doesn't resolve the decision of which thread fetches a new response anyway. Solution A: Prefetching in a daemon process/thread per httpd instance The request processing flow would be most unlikely to block for stapling if a daemon is responsible for maintaining the cache and the request thread never has to look anything up. That leaves a race between prefetching the first time and requests hitting the server right after server startup. (Browsers may report an error to the user when tryLater is returned.) The daemon would try to renew stapling responses ahead of the time that the existing response could no longer be used. If it can't, the error path on the request thread would be the same as the current handling of an inability to fetch a new response. Solution B: Fetch on demand largely like current code, but utilize a separate Fetch mutex Hold the stapling cache mutex just while reading from/writing to the cache; grab the Fetch mutex when needing to perform a lookup. (Once obtaining the Fetch mutex, you'd need to look in the cache again to see if another request thread did the lookup/store while waiting for the Fetch mutex.) By itself this doesn't solve potentially blocking a bunch of initial handshakes when performing a lookup, but at least it solves blocking requests that already have a cached response (different certificate) when performing a lookup. A fairly simple improvement to this would be to have a small number of Fetch mutexes, where each certificate maps to a specific fetch mutex (but not vice versa), so that lookups for multiple certificates could be done at once. This doesn't solve blocking all initial handshakes for a certificate that needs a fresh response, or completely solve blocking those for other certificates that need a fresh response (since multiple certificates could map to the same Fetch mutex). Solution C: Hybrid of A and B The request thread implements solution B but generally a lookup on the request thread won't be needed since the daemon has already done the work. But at server startup the daemon and the request threads might fight over the Fetch mutex until responses for commonly-used certificates had been obtained/cached. This solves a potential lack of responses at server startup. Since the request thread is able to do the work in a pinch, this lends itself to a SSLStaplingPrefetch On|Off directive that could be used to disable the prefetch daemon. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: Looking ahead to 2.4.13 / 2.2.30
Thx! On May 1, 2015, at 3:29 PM, Ben Reser b...@reser.org wrote: On 4/30/15 2:52 PM, William A Rowe Jr wrote: It seems that we have 2 groups of good things to come out of ApacheCon, some immediate fixes for things like BSD project efforts, some pretty straightforward defects that have been resolved... and then there's a bunch of energy about enhancements and the h2 universe. In the short term, WDYT about giving the trees a week to settle, grab the low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this coming week? Guessing Jim's up for RM'ing 2.4.13, and I'm happy to TR 2.2.30 in tandem. Concerns / observations / thoughts? I have a mod_dav fix that really ought to be in the next 2.4 release. I'll get it committed and nominated sometime this weekend.
Re: Looking ahead to 2.4.13 / 2.2.30
On 5/3/15 8:05 AM, Jim Jagielski wrote: Thx! On May 1, 2015, at 3:29 PM, Ben Reser b...@reser.org wrote: On 4/30/15 2:52 PM, William A Rowe Jr wrote: It seems that we have 2 groups of good things to come out of ApacheCon, some immediate fixes for things like BSD project efforts, some pretty straightforward defects that have been resolved... and then there's a bunch of energy about enhancements and the h2 universe. In the short term, WDYT about giving the trees a week to settle, grab the low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this coming week? Guessing Jim's up for RM'ing 2.4.13, and I'm happy to TR 2.2.30 in tandem. Concerns / observations / thoughts? I have a mod_dav fix that really ought to be in the next 2.4 release. I'll get it committed and nominated sometime this weekend. My fix is committed and backports nominated. If someone can look at them it'd be appreciated.
