You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Igor Galić <i....@brainsware.org> on 2013/04/18 17:09:46 UTC
Interpolating %{variables} in all directives
Hey folks o/~
>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.
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>
Another example might be something "more advanced" like:
# group specific authorization:
<LocationMatch "^/(?P<group>[^/]+).*">
Require group %{group}
</Location>
So long,
-- i
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: Interpolating %{variables} in all directives
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> Consistency would be a major enhancement. the best solution would be
> to
> have it enabled without any change to current modules implementation.
> Yes, it would be incompatible with the modules that implemented their
> own parsing, but why not establish a new standard for httpd 3?
> For 2.x, a trade-off could be found. I am partisan to allow the admin
> to
> register the modules to exclude from the parsing (like rewrite, etc.)
I was thinking of a similar mechanism we have or use for AllowOverride
or AllowOverrideList in 2.4
-- i
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: Interpolating %{variables} in all directives
Posted by Nick Gearls <ni...@gmail.com>.
Consistency would be a major enhancement. the best solution would be to
have it enabled without any change to current modules implementation.
Yes, it would be incompatible with the modules that implemented their
own parsing, but why not establish a new standard for httpd 3?
For 2.x, a trade-off could be found. I am partisan to allow the admin to
register the modules to exclude from the parsing (like rewrite, etc.)
On 18-04-2013 17:33, Daniel Gruno wrote:
> On 04/18/2013 05:09 PM, Igor Galić wrote:
>> Hey folks o/~
>>
>> 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.
>>
>> 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>
>>
>>
>> Another example might be something "more advanced" like:
>>
>> # group specific authorization:
>> <LocationMatch "^/(?P<group>[^/]+).*">
>> Require group %{group}
>> </Location>
>>
>>
> I'm for interpolating in as many places as makes sense, but I'm probably
> not for interpolating eeeeverywhere at once, since that could lead to
> clashes and unwanted results. Interpolation should be enabled in each
> module that wants to use this, and not via a blanket config change (this
> probably isn't viable/possible anyway), but I'm definitely for using it
> in areas such as Redirect*, Location*, Header* and possibly Require
> (although that one might be a tad difficult and would have to be
> implemented locally in each individual auth module I suspect).
>
> So, +1 to the general idea, but I think it would/should be enabled
> 'manually' in each module, and not some attempt to just make it all
> switch at once. Perhaps we could start with Redirect*?
>
> With regards,
> Daniel.
> .
>
Re: Interpolating %{variables} in all directives
Posted by Daniel Gruno <ru...@cord.dk>.
On 04/18/2013 05:09 PM, Igor Galić wrote:
>
> Hey folks o/~
>
> 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.
>
> 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>
>
>
> Another example might be something "more advanced" like:
>
> # group specific authorization:
> <LocationMatch "^/(?P<group>[^/]+).*">
> Require group %{group}
> </Location>
>
>
I'm for interpolating in as many places as makes sense, but I'm probably
not for interpolating eeeeverywhere at once, since that could lead to
clashes and unwanted results. Interpolation should be enabled in each
module that wants to use this, and not via a blanket config change (this
probably isn't viable/possible anyway), but I'm definitely for using it
in areas such as Redirect*, Location*, Header* and possibly Require
(although that one might be a tad difficult and would have to be
implemented locally in each individual auth module I suspect).
So, +1 to the general idea, but I think it would/should be enabled
'manually' in each module, and not some attempt to just make it all
switch at once. Perhaps we could start with Redirect*?
With regards,
Daniel.
Re: Interpolating %{variables} in all directives
Posted by Stefan Fritsch <sf...@sfritsch.de>.
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
Re: Interpolating %{variables} in all directives
Posted by Nick Gearls <ni...@gmail.com>.
On 23-04-2013 19:40, Vincent Deffontaines wrote:
> Last point, who knows, maybe using interpolation together with
> mod_macro/mod_rewrite will be the next great thing that we didn't think
> of, and this config will even let super clever admins invent it for
> us;)
especially mod_define
Re: Interpolating %{variables} in all directives
Posted by Igor Galić <i....@brainsware.org>.
> Last point, who knows, maybe using interpolation together with
> mod_macro/mod_rewrite will be the next great thing that we didn't
> think
> of, and this config will even let super clever admins invent it for
> us ;)
who then go on to write books about it and become Rich and famous.
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: Interpolating %{variables} in all directives
Posted by Vincent Deffontaines <vi...@gryzor.com>.
Le Thu, 18 Apr 2013 11:29:29 -0400,
Rich Bowen <rb...@rcbowen.com> a écrit :
>
> On Apr 18, 2013, at 11:09 AM, 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.
> >
> > 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>
> >
> >
> > Another example might be something "more advanced" like:
> >
> > # group specific authorization:
> > <LocationMatch "^/(?P<group>[^/]+).*">
> > Require group %{group}
> > </Location>
>
> This would be lovely, and make us as cool as nginx.
>
> Problems to address include conflicts with mod_macro, mod_rewrite,
> and any third-party module which might do variable fu.
>
> Having the interpolation ignore stuff starting with Rewrite* or in a
> mod_macro definition seems simple enough. Having a generic way for a
> third-party module to say "don't interpolate me, man!" could be handy
> too.
>
Hi,
I see no reason why it should be enabled per module, as I guess some
admins might want it for some parts of config, and not others (including
the .htaccess performance parsing point).
How about introducing a new <Interpolate> context ?
Default : off
Possibly a "AllowOverride Interpolate", so the main admin decides
whether .htaccess can make the server really slow.
Also solves the rewrite/macro conflicts issues at the config level :
<Interpolate On>
<Directory /foo/bar>
... interpolated stuff
</Directory>
</Interpolate>
<Interpolate Off>
<Directory /foo/bar>
... My rewrite/macro/etc stuff
</Directory>
</Interpolate>
This would also be fully compatible with 2.X existing configs and
respect their behaviour as long as nothing is changed.
Last point, who knows, maybe using interpolation together with
mod_macro/mod_rewrite will be the next great thing that we didn't think
of, and this config will even let super clever admins invent it for
us ;)
I suppose this might require more work to implement, though.
Vincent
--
Stop chasing shadows, just enjoy the ride.
Morcheeba
Re: Interpolating %{variables} in all directives
Posted by Rich Bowen <rb...@rcbowen.com>.
On Apr 18, 2013, at 11:09 AM, 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.
>
> 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>
>
>
> Another example might be something "more advanced" like:
>
> # group specific authorization:
> <LocationMatch "^/(?P<group>[^/]+).*">
> Require group %{group}
> </Location>
This would be lovely, and make us as cool as nginx.
Problems to address include conflicts with mod_macro, mod_rewrite, and any third-party module which might do variable fu.
Having the interpolation ignore stuff starting with Rewrite* or in a mod_macro definition seems simple enough. Having a generic way for a third-party module to say "don't interpolate me, man!" could be handy too.
--
Rich Bowen
rbowen@rcbowen.com
Shosholoza
Re: Interpolating %{variables} in all directives
Posted by Tom Evans <te...@googlemail.com>.
On Thu, Apr 18, 2013 at 4:09 PM, Igor Galić <i....@brainsware.org> wrote:
>
> Hey folks o/~
>
> 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.
>
> 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>
>
>
> Another example might be something "more advanced" like:
>
> # group specific authorization:
> <LocationMatch "^/(?P<group>[^/]+).*">
> Require group %{group}
> </Location>
>
>
> So long,
>
Currently it doesn't matter how long it takes to process a directive,
it only happens twice at server startup. If any variable can be
interpolated, this would mean re-running any interpolated directive
processing at the time of the request.
Mostly this would be fine, but it would be very different to
everything that went before.
Cheers
Tom