Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Subject: Re: Supporting "SSL:" in the expression parser via mod_ssl
To: dev@httpd.apache.org
References: <560C5386.1030700@kippdata.de> <3128045.1Bge59dzo2@k>
From: Rainer Jung <rainer.jung@kippdata.de>
Message-ID: <56139AAF.3040706@kippdata.de>
Date: Tue, 6 Oct 2015 11:55:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <3128045.1Bge59dzo2@k>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Am 06.10.2015 um 00:44 schrieb Stefan Fritsch:
> On Wednesday 30 September 2015 23:26:30, Rainer Jung wrote:
>> I noticed that currently the expression parser in 2.4/trunk does not
>> support the SSL:VARIABLE lookups that mod_rewrite supports.
>>
>> The expression parser uses ":" as an alternative function call
>> syntax, so HTTP:VARIABLE is the same as HTTP(VARIABLE) which in
>> turn executes http(VARIABLE). The same is true for ENV:VARIABLE
>> which maps to env(VARIABLE) etc.
>>
>> We already do support the syntax SSL_VARIABLE to look up SSL
>> variables, because mod_ssl registers in the expression parser for
>> variables whose name starts with "SSL_". But mod_ssl does not
>> register for a function named SSL (or ssl), so the SSL: notation
>> does not work.
>>
>> Is that just an omission, or was that intentional? If not
>> intentional, I would apply the following (yet untested) simple
>> patch to trunk mod_ssl and propose for backport. It registers the
>> SSL (and ssl) function in the expression parser:
>
> I think that was just an omission. +1 to your patch.

I tested it an it would work, but one implementation detail remains to 
discuss. The %{SSL:variable} syntax goes back to mod_rewrite. There 
"variable" is the full name of the mod_ssl variable, i.e.

    %{SSL:SSL_PROTOCOL}

mod_rewrite looked up varname by calling ssl_var_lookup() which itself 
resolves lots of variables, even many non-ssl ones. In the ssl case it 
quickly falls through and then strips the "SSL_" prefix and calls 
ssl_var_lookup_ssl().

For 2.4 and the nes %{SSL:variable} impl in the expr parser we have 
three options:

1) Support only variable name with the "SSL_" prefix already stripped 
and call ssl_var_lookup_ssl().

Example: %{SSL:PROTOCOL}

There's less redundancy in the notation, but it is incompatible with 
mod_rewrite's use of %{SSL:variable}. Therefore I'd say it is too 
confusing and would be -1 to this option.

2) Demand including the "SSL_" prefix in the variable name, strip it 
when resolving the value and call ssl_var_lookup_ssl() for the shortened 
name. Throw error if the variable name does not start with "SSL_".

Example: %{SSL:SSL_PROTOCOL}

This is compatible with mod_rewrite, but only as long as you really use 
a variable whose name begins with "SSL_". I guess mostly this will be 
the case, but people might have used e.g. %{SSL:HTTPS}, which would now 
throw an error.

3) Support any mod_ssl variable. Demand using the original full name and 
call ssl_var_lookup() with the full name.

Example: %{SSL:SSL_PROTOCOL}

This is the most compatible and complete solution. The only drawback is 
the use of ssl_var_lookup() which adds a bit of overhead for the general 
case and itself seems to be a candidate for long term replacement by 
ap_expr. At that point in the future it would bite us to let ap_expr 
base its SSL: implementation on a function, that could be replaced by 
ap_expr itself (and ssl_var_lookup_ssl()). Nevertheless I would vote for 
3) as the solution to chose.

I will commit 3) but are very open to other opinions before suggesting a 
backport.

Regards,

Rainer