Changeset 61e802c in mod_gnutls


Ignore:
Timestamp:
Apr 19, 2018, 3:22:11 PM (2 years ago)
Author:
Fiona Klute <fiona.klute@…>
Branches:
debian/master, master, proxy-ticket
Children:
3d30543
Parents:
3c475e0
Message:

Simplify mgs_async_ocsp_update

Always use OCSP mutex for updates, update comment, rename server_rec*
for readability.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • src/gnutls_ocsp.c

    r3c475e0 r61e802c  
    947947        return APR_SUCCESS;
    948948
    949     server_rec *s = (server_rec *) data;
     949    server_rec *server = (server_rec *) data;
    950950    mgs_srvconf_rec *sc = (mgs_srvconf_rec *)
    951         ap_get_module_config(s->module_config, &gnutls_module);
     951        ap_get_module_config(server->module_config, &gnutls_module);
    952952    apr_time_t expiry = 0;
    953953
    954     /* Callbacks registered to one watchdog instance are run
    955      * sequentially. Child watchdog threads are created in a
    956      * child_init hook, but it doesn't guarantee when callbacks will
    957      * be called for the first time.
    958      *
    959      * Using the mutex should help avoiding duplicate OCSP requests
    960      * (async and during request handling) if requests arrive before
    961      * the startup run completes. However, an early request might
    962      * still get in between initial OCSP caching calls. */
    963     if (state == AP_WATCHDOG_STATE_STARTING)
    964         apr_global_mutex_lock(sc->ocsp_mutex);
    965     apr_status_t rv = mgs_cache_ocsp_response(s, &expiry);
    966     if (state == AP_WATCHDOG_STATE_STARTING)
    967         apr_global_mutex_unlock(sc->ocsp_mutex);
     954    /* Holding the mutex should help avoiding simultaneous synchronous
     955     * and asynchronous OCSP requests in some edge cases: during
     956     * startup if there's an early request, and if OCSP requests fail
     957     * repeatedly until the cached response expires and a synchronous
     958     * update is triggered before a failure cache entry is
     959     * created. Usually there should be a good OCSP response in the
     960     * cache and the mutex is never touched in
     961     * mgs_get_ocsp_response. */
     962    apr_global_mutex_lock(sc->ocsp_mutex);
     963    apr_status_t rv = mgs_cache_ocsp_response(server, &expiry);
    968964
    969965    /* TODO: fuzzy interval */
     
    973969    sc->singleton_wd->set_callback_interval(sc->singleton_wd->wd,
    974970                                            next_interval,
    975                                             s, mgs_async_ocsp_update);
    976 
    977     /* TODO: cache error if no cache entry present to inhibit
    978      * request-triggered updates */
    979     ap_log_error(APLOG_MARK, rv == APR_SUCCESS ? APLOG_DEBUG : APLOG_ERR, rv, s,
     971                                            server, mgs_async_ocsp_update);
     972
     973    ap_log_error(APLOG_MARK, rv == APR_SUCCESS ? APLOG_DEBUG : APLOG_WARNING,
     974                 rv, server,
    980975                 "Async OCSP update %s for %s:%d, next update in "
    981976                 "%" APR_TIME_T_FMT " seconds.",
    982977                 rv == APR_SUCCESS ? "done" : "failed",
    983                  s->server_hostname, s->addrs->host_port,
     978                 server->server_hostname, server->addrs->host_port,
    984979                 apr_time_sec(next_interval));
     980
     981    apr_global_mutex_unlock(sc->ocsp_mutex);
    985982
    986983    return APR_SUCCESS;
Note: See TracChangeset for help on using the changeset viewer.