Hi,

On Thursday 18 April 2013, Igor Galić wrote:
> From an IRC conversation in #httpd and #httpd-dev emerged the
> idea to interpolate %{variables} in all directives.
> According to sf we have somewhere a ~10 line code fragment
> which does that without much overhead (not benchmarked) when
> interpolating and with hardly any (short-circuit) when not.

The the overhead when interpolating would really need to be measured. 
In some use cases it may be relevant. And in .htaccess it would 
definitely be noticable, because the parsing happens during request 
time. This may be somewhat reduced if we add a short-circuit also for 
parsing, but that is not done, yet.

Also, to clarify, this would need to change the code for every use of 
a string from the config. This means it would be quite some work. In 
some cases, where there significant preparation going on at server 
startup, it may even be impossible to interpolate the string at 
runtime without intrusive changes. In any case, I would concentrate on 
the most useful cases and not aim for 'all directives' (yet?).

> I think it would be a good idea to allow for this to be used
> in all directives (across all modules) it makes for immensly
> more readable configurations because:
> 
> Example:
> 
>     # default vhost redirecting every HTTP vhost to HTTPS:
>     <VirtualHost *:80>
>         Redirect / https://%{HTTP_HOST}/
>     </VirtualHost>


But the above is an example where it definitely makes sense. There are 
quite a few others. ProxyPass comes to mind immediately.

In some cases, it would make sense but there are conflicts with 
existing syntax. For example, RequestHeader has its own variable 
expansion (e.g. %{VARNAME}e). If anyone has a good idea how to support 
both the legacy scheme and the ap_expr syntax without having to add a 
load of new directives, I would be very interested to hear it.


> Another example might be something "more advanced" like:
> 
>     # group specific authorization:
>     <LocationMatch "^/(?P<group>[^/]+).*">
>         Require group %{group}
>     </Location>


This would not work, though. At least not without significant 
additional work. But the idea with named capturing sub-expressions is 
rather nice. I need to think a bit more about it.

Cheers,
Stefan

Reply via email to