ocsp stapling global mutex

[Paul Querna]

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?

Thoughts?

Thanks,

Paul

r-handler and non-filesystem requests, mod_status

[Jeff Trawick]

On Thu, Jun 24, 2010 at 9:11 AM, Jeff Trawick traw...@gmail.com wrote:
 On Thu, Jun 24, 2010 at 9:00 AM, Eric Covener cove...@gmail.com wrote:
 A general capability would need to be added to the server to handle
 this situation (e.g., restrict one/all handler adjustment from
 .htaccess when FileInfo can be overridden, or something else
 altogether).

 How about two mod_status directives:

  * option for ServerStatus ON|OFF valid in Location
  * a per-server option to only respond to the new flag

 Perhaps with differing defaults for the latter in 2.2 and 2.4

 mod_info, mod_anything-activated-via-sethandler

hmmm, maybe the big picture isn't what I think it is...

here's what I see from looking at an issue in a third-party module:

* the module is activated via SetHandler
* the module ought to bypass directory walk (like mod_status/mod_info
in theory, though they don't implement that)
* core doesn't set r-handler from SetHandler until fixups hook
** the handler setting is readily available in translate name from
core's dir config, but that isn't an API

somewhat related issues:
* I think using mod_rewrite or some other mechanism to set r-handler
to override some module that thought it was a non-filesystem-request
could be broken (directory walk already bypassed)

Either

r-handler should be available prior to translate name
 (don't-do-that if mod_rewrite/mod_foo resets r-handler to a
filesystem request after directory walk was bypassed
  || directory walk should be triggered when needed (ha!))

or

non-filesystem requests shouldn't set/look at/otherwise rely on
r-handler until fixups

---/---

If the latter, then mod_status could/should be changed to use its own
enablement flag instead of SetHandler for multiple reasons (bypassing
dir-walk and .htaccess issues).

--/--

Thoughts?  Any expertise on the nuances of r-handler to be shared?

Re: httpd-trunk - NetWare build - observations.

[William A. Rowe Jr.]

On 6/23/2010 5:50 PM, NormW wrote:
 Greetings,
 Some observations when compiling current httpd-trunk for NetWare
 following recent updates:
...
 5. modules\lua\lua_request.c build now fails following recent updates:
 
 Compiling lua_request.c
 ### mwccnlm Compiler:
 #File: lua_request.c
 # --
 # 335:  req_field_apr_table_f func = rft-fun;
 #   Error:   ^
 #   illegal implicit conversion from 'const void *' to
 #   'struct apr_table_t * (*)(struct request_rec *)'
 ### mwccnlm Compiler:
 # 345:  lua_CFunction func = rft-fun;
 #   Error:   ^
 #   illegal implicit conversion from 'const void *' to
 #   'int (*)(struct lua_State *)'
 ### mwccnlm Compiler:
 # 353:  req_field_string_f func = rft-fun;
 #   Error:^
 #   illegal implicit conversion from 'const void *' to
 #   'char * (*)(struct request_rec *)'
 ### mwccnlm Compiler:
 # 362:  req_field_int_f func = rft-fun;
 #   Error: ^
 #   illegal implicit conversion from 'const void *' to
 #   'int (*)(struct request_rec *)'
 ### mwccnlm Compiler:
 # 371:  req_field_int_f func = rft-fun;
 #   Error: ^
 #   illegal implicit conversion from 'const void *' to
 #   'int (*)(struct request_rec *)'
 
 As noted, these are 'observations', and for NetWare... not really a dev
 as such, so no real idea what represents bugs or solutions.

A void * fn() isn't a void * (evidenced on all sorts of wacky architectures),
so this is a flaw.