Re: svn commit: r1692486 [1/2] - in /httpd/httpd/trunk: docs/log-message-tags/ include/ modules/http2/ modules/ssl/ server/

2015-08-17 Thread Stefan Eissing 
Done in r1696266.

> Am 24.07.2015 um 15:54 schrieb Ruediger Pluem :
 +
 +/* make sure httpd closes the connection after this */
 +c->keepalive = AP_CONN_CLOSE;
 +ap_lingering_close(c);
 +
 +if (c->sbh) {
 +ap_update_child_status_from_conn(c->sbh, 
 + SERVER_CLOSING, 
 c);
 +}
>>> 
>>> The c->keepalive = AP_CONN_CLOSE looks fine to me, but why should we do the 
>>> other stuff in a handler.
>>> IMHO that should be done by the existing code.
>> 
>> Not sure I understand. You mean the interim response or the whole handler?
> 
> No I mean the
> 
> ap_lingering_close(c);
> 
> and the scoreboard update.
> 
> Regards
> 
> Rüdiger
> 

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: svn commit: r1692486 [2/2] - in /httpd/httpd/trunk: docs/log-message-tags/ include/ modules/http2/ modules/ssl/ server/

2015-08-17 Thread Stefan Eissing 

> Am 24.07.2015 um 15:51 schrieb Ruediger Pluem :
>> 
>> +/* Something like this must be in APR, only I do not find it... */
>> +static int array_index(apr_array_header_t *array, const char *s)
>> +{
>> +int i;
>> +for (i = 0; i < array->nelts; i++) {
>> +const char *p = APR_ARRAY_IDX(array, i, const char *);
>> +if (!strcmp(p, s)) {
>> +return i;
>> +}
>> +}
>> +return -1;
>> +}
> 
> If not in APR it should probably be put into util.c and made ap_array_index.
> Once in APR it could be converted into a wrapper macro around the APR 
> function.

Checked in as r1696264.

//Stefan

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: svn commit: r1672014 - in /httpd/httpd/trunk: CHANGES server/config.c

2015-08-17 Thread Kaspar Brand 
On 14.8.15 20:01, Eric Covener wrote:
> On Wed, Apr 15, 2015 at 12:02 PM, Kaspar Brand  
> 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
> 
>   SSLSomethingThatWouldWarn
>   LogLevel warn
> 
> 
> 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

  ServerName example.net
  DefaultType text/plain


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