On 14.8.15 20:01, Eric Covener wrote: > On Wed, Apr 15, 2015 at 12:02 PM, Kaspar Brand <[email protected]> > wrote: >> The other option to fix the problem which originally triggered this >> investigation would be to simply replace "cmd->server" in >> ssl_engine_config.c:836 with "NULL", though it would only fix this >> particular case, and not help with other places with the same underlying >> problem. > > What are the different scenarios that are bad in 2.4? I stumbled on > this thread on a search about a related topic. > > I think this is the immediate one, but I really don't like the idea of > using the default loglevel there: > > LogLevel crit > <virtualhost *:443> > SSLSomethingThatWouldWarn > LogLevel warn > </virtualhost> > > What are the other variants?
That's basically the pattern I meant. With "other places with the same underlying problem", I was referring to other modules which use cmd->server for logging during ap_process_config_tree walking (and before ap_fixup_virtual_hosts is called). There are a number of "ap_log_error(..., cmd->server, ...)" occurrences in mod_env, mod_ldap, mod_proxy, mod_authnz_ldap, mod_auth_digest, mod_file_cache, mod_rewrite, and mod_alias, and in particular when they are using APLOG_WARNING, these messages are not logged unless there's a preceding LogLevel statement in the respective VirtualHost block. server/core.c on the other hand also has a few places where this problem occurs, here's an example: LogLevel warn <VirtualHost *:80> ServerName example.net DefaultType text/plain </VirtualHost> The "Ignoring deprecated use of DefaultType..." message is only output if an additional "LogLevel warn" statement in the VirtualHost block is inserted (which must appear before the DefaultType statement). Kaspar
