Re: log config and variables

2021-05-18 Thread Stefan Eissing
Done in r1890003.

> Am 17.05.2021 um 21:25 schrieb Ruediger Pluem :
> 
> 
> 
> On 5/17/21 4:44 PM, Yann Ylavic wrote:
>> On Mon, May 17, 2021 at 3:17 PM Eric Covener  wrote:
>>> 
>>> On Mon, May 17, 2021 at 8:47 AM Stefan Eissing
>>>  wrote:
 
 With possibly multiple SSL modules active in our server, I am looking what 
 to do about the logging configuration.
 
 The current situation: mod_ssl registers log handler for tags "x" and "c". 
 Those do
 - "x" does a lookup of the SSL_* variable name
 - "c" does a shorthand translation of 6 variables names to the ones 
 available via "x". In addition it gives "-" as value for "errcode" and the 
 client verification error for "errstr".
 
 The problem is that there can only be one(!) handler registered for a tag.
 
 Now "x" can be easily done in mod_log_config itself now what we have 
 ap_ssl_var_lookup() in the core server. This means we can move that code 
 from mod_ssl to mod_log_config.
>>> 
>>> +1
>> +1
>> 
>>> 
 To make the "c" handler work in core, we can also move the code from 
 mod_ssl to mod_log_config. But we need to define a variable name for the 
 "errstr", for example as "SSL_CLIENT_VERIFY_ERRSTR" which mod_ssl needs to 
 supply then.
>>> 
>>> If you mean ssl_var_lookup would handle "SSL_CLIENT_VERIFY_ERRSTR" +1
>> +1
>> 
> 
> +1 to both above.
> 
> Regards
> 
> RĂ¼diger



Re: log config and variables

2021-05-17 Thread Ruediger Pluem



On 5/17/21 4:44 PM, Yann Ylavic wrote:
> On Mon, May 17, 2021 at 3:17 PM Eric Covener  wrote:
>>
>> On Mon, May 17, 2021 at 8:47 AM Stefan Eissing
>>  wrote:
>>>
>>> With possibly multiple SSL modules active in our server, I am looking what 
>>> to do about the logging configuration.
>>>
>>> The current situation: mod_ssl registers log handler for tags "x" and "c". 
>>> Those do
>>> - "x" does a lookup of the SSL_* variable name
>>> - "c" does a shorthand translation of 6 variables names to the ones 
>>> available via "x". In addition it gives "-" as value for "errcode" and the 
>>> client verification error for "errstr".
>>>
>>> The problem is that there can only be one(!) handler registered for a tag.
>>>
>>> Now "x" can be easily done in mod_log_config itself now what we have 
>>> ap_ssl_var_lookup() in the core server. This means we can move that code 
>>> from mod_ssl to mod_log_config.
>>
>> +1
> +1
> 
>>
>>> To make the "c" handler work in core, we can also move the code from 
>>> mod_ssl to mod_log_config. But we need to define a variable name for the 
>>> "errstr", for example as "SSL_CLIENT_VERIFY_ERRSTR" which mod_ssl needs to 
>>> supply then.
>>
>> If you mean ssl_var_lookup would handle "SSL_CLIENT_VERIFY_ERRSTR" +1
> +1
> 

+1 to both above.

Regards

RĂ¼diger


Re: log config and variables

2021-05-17 Thread Yann Ylavic
On Mon, May 17, 2021 at 3:17 PM Eric Covener  wrote:
>
> On Mon, May 17, 2021 at 8:47 AM Stefan Eissing
>  wrote:
> >
> > With possibly multiple SSL modules active in our server, I am looking what 
> > to do about the logging configuration.
> >
> > The current situation: mod_ssl registers log handler for tags "x" and "c". 
> > Those do
> > - "x" does a lookup of the SSL_* variable name
> > - "c" does a shorthand translation of 6 variables names to the ones 
> > available via "x". In addition it gives "-" as value for "errcode" and the 
> > client verification error for "errstr".
> >
> > The problem is that there can only be one(!) handler registered for a tag.
> >
> > Now "x" can be easily done in mod_log_config itself now what we have 
> > ap_ssl_var_lookup() in the core server. This means we can move that code 
> > from mod_ssl to mod_log_config.
>
> +1
+1

>
> > To make the "c" handler work in core, we can also move the code from 
> > mod_ssl to mod_log_config. But we need to define a variable name for the 
> > "errstr", for example as "SSL_CLIENT_VERIFY_ERRSTR" which mod_ssl needs to 
> > supply then.
>
> If you mean ssl_var_lookup would handle "SSL_CLIENT_VERIFY_ERRSTR" +1
+1


Re: log config and variables

2021-05-17 Thread Eric Covener
On Mon, May 17, 2021 at 8:47 AM Stefan Eissing
 wrote:
>
> With possibly multiple SSL modules active in our server, I am looking what to 
> do about the logging configuration.
>
> The current situation: mod_ssl registers log handler for tags "x" and "c". 
> Those do
> - "x" does a lookup of the SSL_* variable name
> - "c" does a shorthand translation of 6 variables names to the ones available 
> via "x". In addition it gives "-" as value for "errcode" and the client 
> verification error for "errstr".
>
> The problem is that there can only be one(!) handler registered for a tag.
>
> Now "x" can be easily done in mod_log_config itself now what we have 
> ap_ssl_var_lookup() in the core server. This means we can move that code from 
> mod_ssl to mod_log_config.

+1

> To make the "c" handler work in core, we can also move the code from mod_ssl 
> to mod_log_config. But we need to define a variable name for the "errstr", 
> for example as "SSL_CLIENT_VERIFY_ERRSTR" which mod_ssl needs to supply then.

If you mean ssl_var_lookup would handle "SSL_CLIENT_VERIFY_ERRSTR" +1


log config and variables

2021-05-17 Thread Stefan Eissing
With possibly multiple SSL modules active in our server, I am looking what to 
do about the logging configuration.

The current situation: mod_ssl registers log handler for tags "x" and "c". 
Those do
- "x" does a lookup of the SSL_* variable name
- "c" does a shorthand translation of 6 variables names to the ones available 
via "x". In addition it gives "-" as value for "errcode" and the client 
verification error for "errstr".

The problem is that there can only be one(!) handler registered for a tag.

Now "x" can be easily done in mod_log_config itself now what we have 
ap_ssl_var_lookup() in the core server. This means we can move that code from 
mod_ssl to mod_log_config.

To make the "c" handler work in core, we can also move the code from mod_ssl to 
mod_log_config. But we need to define a variable name for the "errstr", for 
example as "SSL_CLIENT_VERIFY_ERRSTR" which mod_ssl needs to supply then.

This change would be 100% backward compatible, I think,  and allow other 
modules to supply their values as well.


If this finds agreement, I will work on the changes in the coming days.

Cheers, Stefan