You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Graham Leggett <mi...@sharp.fm> on 2014/01/26 23:11:51 UTC
Simplifying mod_alias
Hi all,
A look at mod_alias shows it has 7 directives:
• Alias
• AliasMatch
• Redirect
• RedirectMatch
• RedirectPermanent
• RedirectTemp
• ScriptAlias
• ScriptAliasMatch
In theory we only need these three:
• Alias
• Redirect
• ScriptAlias
What I'm keen to do is enable expression support and deprecate all but the above, with the following as the preferred configuration method (same as the one used by ProxyPass):
<Location /foo>
Alias /var/lib/bar
…stuff...
</Location>
or
<LocationMatch ^/foo/(?<bar>[^/]+)>
Alias /var/lib/%{env:MATCH_BAR}/baz
…stuff...
</LocationMatch>
In theory this would be faster as we would not be scanning the list of Aliases followed by the list of Locations each time, and things get a lot simpler to use.
Thoughts?
Regards,
Graham
--
Re: [Patch] Simplifying mod_alias
Posted by Ruediger Pluem <rp...@apache.org>.
On 12/21/2014 02:48 PM, Graham Leggett wrote:
> On 27 Jan 2014, at 12:11 AM, GRAHAM LEGGETT <mi...@sharp.fm> wrote:
>
>> A look at mod_alias shows it has 7 directives:
>>
>> • Alias
>> • AliasMatch
>> • Redirect
>> • RedirectMatch
>> • RedirectPermanent
>> • RedirectTemp
>> • ScriptAlias
>> • ScriptAliasMatch
>>
>> In theory we only need these three:
>>
>> • Alias
>> • Redirect
>> • ScriptAlias
>>
>> What I'm keen to do is enable expression support and deprecate all but the above, with the following as the preferred configuration method (same as the one used by ProxyPass):
>>
>> <Location /foo>
>> Alias /var/lib/bar
>> …stuff...
>> </Location>
>>
>> or
>>
>> <LocationMatch ^/foo/(?<bar>[^/]+)>
>> Alias /var/lib/%{env:MATCH_BAR}/baz
>> …stuff...
>> </LocationMatch>
>>
>> In theory this would be faster as we would not be scanning the list of Aliases followed by the list of Locations each time, and things get a lot simpler to use.
>
> This patch implements the above.
>
Only one small comment on the test cases:
Doesn't the httpd.conf parts need to be in an ifversion block to ensure the test suite still runs with 2.4.x / 2.2.x?
Regards
Rüdiger
Re: [Patch] Simplifying mod_alias
Posted by Reindl Harald <h....@thelounge.net>.
Am 22.12.2014 um 14:26 schrieb Graham Leggett:
> On 22 Dec 2014, at 14:53, Reindl Harald <h....@thelounge.net> wrote:
>
>> as user i will tell you something about the "without any notable problems": if you use the new directives in the main configuration and somewhere below (vhost or even .htaccess) compat directives you get undefined behavior
>>
>> been there done that
>
> The compat module being discussed in this thread doesn't exist yet, so you could not have been there nor done that.
read my post again including the part you stripped
i refered to the "major changes occurred between httpd v2.2 and v2.4 in
authnz and this passed by without any notable problems"
Re: [Patch] Simplifying mod_alias
Posted by Graham Leggett <mi...@sharp.fm>.
On 22 Dec 2014, at 14:53, Reindl Harald <h....@thelounge.net> wrote:
> as user i will tell you something about the "without any notable problems": if you use the new directives in the main configuration and somewhere below (vhost or even .htaccess) compat directives you get undefined behavior
>
> been there done that
The compat module being discussed in this thread doesn't exist yet, so you could not have been there nor done that.
Regards,
Graham
--
Re: [Patch] Simplifying mod_alias
Posted by Reindl Harald <h....@thelounge.net>.
Am 22.12.2014 um 11:15 schrieb Graham Leggett:
> On 21 Dec 2014, at 10:48 PM, Eric Covener <co...@gmail.com> wrote:
>> I don't see how adding expression or <Location> support as
>> necessitating, or benefiting in a meaningful way, from the deprecation
>> / movement of the "other" directives. I am assuming the *match
>> directives could either a) provide their own contexts for the
>> back-references to work or b) simply have their 2nd parameter
>> evaluated the way it is today.
>
> The expression support is a superset of the regex support, making the regex support redundant.
>
> The *Match parameters are self contained, you cannot make a backreference outside the scope of that single directive. In contrast the LocationMatch/DirectoryMatch sections are not self contained, their backreferences are exposed to expressions and can be used and reused in many unrelated directives.
>
> I have heard growing criticism of httpd for being too complicated, and this is an attempt to address that. Supporting 7 directives to do the job of just 3 makes people’s eyes bleed.
>
> The aim of the _compat module is to ensure that existing users are not left in the lurch, they load the compat module and life continues as before. We already have clear precedence of this working well - major changes occurred between httpd v2.2 and v2.4 in authnz and this passed by without any notable problems.
as user i will tell you something about the "without any notable
problems": if you use the new directives in the main configuration and
somewhere below (vhost or even .htaccess) compat directives you get
undefined behavior
been there done that
the result was rewrite *900 vhost configs* on a lot of machines using
mod_version and test that over weeks to have a uninterrupted upgrade
path - please don't pretend such changes are nice for users at all
they are only nice for the few users which don't really matter with
their httpd and a single vhost on a notebook but not on serious setups
where admins are not overwheelmed with 7 directives
frankly even for hobby users it's a problem because in the future you
need to take care if the new hoster supports the compat-module and how
to deal with .htaccess files in case you copy things to different hosts
with different confogurtaions and httpd versions
Re: [Patch] Simplifying mod_alias
Posted by Graham Leggett <mi...@sharp.fm>.
On 31 Dec 2014, at 5:56 PM, Eric Covener <co...@gmail.com> wrote:
> For a URL of http://example.com/foo/bar/baz.html
>
> # this matches against baz.html only
> <FilesMatch (.*\.html)$>
> Redirect http://other.example.com/$1
> </FilesMatch
>
> You would not have any way to match or capture some part of /foo/bar/.
> You could use the entire URL in an expression, but I think it would
> be difficult to tease it apart, and even making it just conditional
> would require something like wrapping in <if>. I think there are some
> big gaps in string-valued expressions, even if you do try to write a
> sophisticated one (this has popped up for me in a handful of contexts
> and I have flailed around in the grammar to no avail)
This limitation affects the whole of the expression API, which covers more and more directives, so if this is a real problem we should fix it.
Would it make sense to add a modifier to FilesMatch to indicate we want to match against the full path instead of just the filename, for example:
<FilesMatch ~ ^/full/(path)/to/(file)$>
Alternatively, what would the impact be of allowing LocationMatch inside htaccess?
Regards,
Graham
—
Re: [Patch] Simplifying mod_alias
Posted by Eric Covener <co...@gmail.com>.
On Wed, Dec 31, 2014 at 10:30 AM, Graham Leggett <mi...@sharp.fm> wrote:
>> I don't think FilesMatch is enough functionally, because you're too
>> limited in what you can check and match.
>
> Can you clarify in more detail? If this is so, I am keen to fix it.
For a URL of http://example.com/foo/bar/baz.html
# this matches against baz.html only
<FilesMatch (.*\.html)$>
Redirect http://other.example.com/$1
</FilesMatch
You would not have any way to match or capture some part of /foo/bar/.
You could use the entire URL in an expression, but I think it would
be difficult to tease it apart, and even making it just conditional
would require something like wrapping in <if>. I think there are some
big gaps in string-valued expressions, even if you do try to write a
sophisticated one (this has popped up for me in a handful of contexts
and I have flailed around in the grammar to no avail)
Re: [Patch] Simplifying mod_alias
Posted by Graham Leggett <mi...@sharp.fm>.
On 31 Dec 2014, at 5:12 PM, Eric Covener <co...@gmail.com> wrote:
> I don't think FilesMatch is enough functionally, because you're too
> limited in what you can check and match.
Can you clarify in more detail? If this is so, I am keen to fix it.
Regards,
Graham
—
Re: [Patch] Simplifying mod_alias
Posted by Eric Covener <co...@gmail.com>.
On Wed, Dec 31, 2014 at 8:57 AM, Graham Leggett <mi...@sharp.fm> wrote:
>> You'll also have two modules and two pages in the manual. The examples
>> for Redirect will now have configuration sections with named
>> back-references and won't work in htaccess.
>
> The FilesMatch container should support htaccess, and if there is a reason it doesn’t work that’s a bug that would be fixed.
I don't think FilesMatch is enough functionally, because you're too
limited in what you can check and match.
Re: [Patch] Simplifying mod_alias
Posted by Eric Covener <co...@gmail.com>.
On Wed, Dec 31, 2014 at 8:57 AM, Graham Leggett <mi...@sharp.fm> wrote:
>> I still don't see any reason to call the existing *Match deprecated to
>> add expression support.
>
> I see no link between the two. I would like to deprecate the *Match directives, but that has no bearing on expression support.
I thought the entire point of the thread was that expression support
in the base directives obsoleted the *Match versions. If you didn't
have the expression support, how would you describe the deprecation of
RedirectMatch to a user? Should they use mod_rewrite?
Re: [Patch] Simplifying mod_alias
Posted by Graham Leggett <mi...@sharp.fm>.
On 22 Dec 2014, at 2:24 PM, Eric Covener <co...@gmail.com> wrote:
> You'll still have 7 directives though. Some of them will be marked
> deprecated because they're less flexible. Sometimes less flexible is a
> sign of simplicity and not something to be relegated to a compat
> module.
The *Match directives (outside of the *Match containers) are definitely not simple - they all support regexes, but the scope of these regexes is limited to that single directive. This is confusing and suffers poor performance.
> You'll also have two modules and two pages in the manual. The examples
> for Redirect will now have configuration sections with named
> back-references and won't work in htaccess.
The FilesMatch container should support htaccess, and if there is a reason it doesn’t work that’s a bug that would be fixed.
> These users whose eyes bleed at the difference between Redirect and
> RedirectMatch or trying to capture the first component of the path
> aren't exactly going to do cartwheels when at the idea of new
> configuration sections and named back-references to accomplish a basic
> task.
I personally would be delighted with such a change.
The expression support inside require directives combined with this change have vastly simplified configurations that made my brain bleed in the past. Template based configuration is now possible where this was difficult before.
> I still don't see any reason to call the existing *Match deprecated to
> add expression support.
I see no link between the two. I would like to deprecate the *Match directives, but that has no bearing on expression support.
Regards,
Graham
—
Re: [Patch] Simplifying mod_alias
Posted by Eric Covener <co...@gmail.com>.
On Mon, Dec 22, 2014 at 5:15 AM, Graham Leggett <mi...@sharp.fm> wrote:
> The expression support is a superset of the regex support, making the regex support redundant.
>
> The *Match parameters are self contained, you cannot make a backreference outside the scope of that single directive. In contrast the LocationMatch/DirectoryMatch sections are not self contained, their backreferences are exposed to expressions and can be used and reused in many unrelated directives.
>
> I have heard growing criticism of httpd for being too complicated, and this is an attempt to address that. Supporting 7 directives to do the job of just 3 makes people’s eyes bleed.
You'll still have 7 directives though. Some of them will be marked
deprecated because they're less flexible. Sometimes less flexible is a
sign of simplicity and not something to be relegated to a compat
module.
You'll also have two modules and two pages in the manual. The examples
for Redirect will now have configuration sections with named
back-references and won't work in htaccess.
These users whose eyes bleed at the difference between Redirect and
RedirectMatch or trying to capture the first component of the path
aren't exactly going to do cartwheels when at the idea of new
configuration sections and named back-references to accomplish a basic
task.
I still don't see any reason to call the existing *Match deprecated to
add expression support.
Re: [Patch] Simplifying mod_alias
Posted by Graham Leggett <mi...@sharp.fm>.
On 21 Dec 2014, at 10:48 PM, Eric Covener <co...@gmail.com> wrote:
> I don't see how adding expression or <Location> support as
> necessitating, or benefiting in a meaningful way, from the deprecation
> / movement of the "other" directives. I am assuming the *match
> directives could either a) provide their own contexts for the
> back-references to work or b) simply have their 2nd parameter
> evaluated the way it is today.
The expression support is a superset of the regex support, making the regex support redundant.
The *Match parameters are self contained, you cannot make a backreference outside the scope of that single directive. In contrast the LocationMatch/DirectoryMatch sections are not self contained, their backreferences are exposed to expressions and can be used and reused in many unrelated directives.
I have heard growing criticism of httpd for being too complicated, and this is an attempt to address that. Supporting 7 directives to do the job of just 3 makes people’s eyes bleed.
The aim of the _compat module is to ensure that existing users are not left in the lurch, they load the compat module and life continues as before. We already have clear precedence of this working well - major changes occurred between httpd v2.2 and v2.4 in authnz and this passed by without any notable problems.
Regards,
Graham
—
Re: [Patch] Simplifying mod_alias
Posted by Eric Covener <co...@gmail.com>.
On Sun, Dec 21, 2014 at 1:57 PM, Graham Leggett <mi...@sharp.fm> wrote:
>> I am -1 on moving them to a _compat module. I don't see a technical
>> reason, there's nothing wrong with the current code or function, and I
>> think there has to be a stronger case to justify adding more upgrade
>> speedbumps.
>
> The primary purpose of the exercise was to formally bring expression support to Alias/Redirect/ScriptAlias and avoid a need to use mod_rewrite for what should be easy and simple.
>
> I don’t follow the argument that there is no technical reason for the change - surely support for the expression API is to be encouraged?
I don't see how adding expression or <Location> support as
necessitating, or benefiting in a meaningful way, from the deprecation
/ movement of the "other" directives. I am assuming the *match
directives could either a) provide their own contexts for the
back-references to work or b) simply have their 2nd parameter
evaluated the way it is today.
Re: [Patch] Simplifying mod_alias
Posted by Graham Leggett <mi...@sharp.fm>.
On 21 Dec 2014, at 7:37 PM, Eric Covener <co...@gmail.com> wrote:
> I am -1 on moving them to a _compat module. I don't see a technical
> reason, there's nothing wrong with the current code or function, and I
> think there has to be a stronger case to justify adding more upgrade
> speedbumps.
The primary purpose of the exercise was to formally bring expression support to Alias/Redirect/ScriptAlias and avoid a need to use mod_rewrite for what should be easy and simple.
I don’t follow the argument that there is no technical reason for the change - surely support for the expression API is to be encouraged?
Regards,
Graham
—
Re: [Patch] Simplifying mod_alias
Posted by Eric Covener <co...@gmail.com>.
On Sun, Dec 21, 2014 at 9:41 AM, Graham Leggett <mi...@sharp.fm> wrote:
> What we should do in future is remove all the *Match directives and move them into a mod_alias_compat module, leaving just Alias/Redirect/ScriptAlias in mod_alias, same as we did with authnz in httpd v2.4.
I am -1 on moving them to a _compat module. I don't see a technical
reason, there's nothing wrong with the current code or function, and I
think there has to be a stronger case to justify adding more upgrade
speedbumps.
Re: [Patch] Simplifying mod_alias
Posted by "Helmut K. C. Tessarek" <te...@evermeet.cx>.
On 21.12.14 9:41 , Graham Leggett wrote:
> What we should do in future is remove all the *Match directives and move
> them into a mod_alias_compat module, leaving just
> Alias/Redirect/ScriptAlias in mod_alias, same as we did with authnz in
> httpd v2.4.
+1.
In SW development a lot of people mixup the type of break: configurational,
behavioral, and functional. One does not necessarily have to imply the other(s).
In any case, this need for backwards compatibilty kills innovation and
advancement. I won't go into details, since it may sound like ranting.
What I want to say though is that Apache's compat modules are a great solution
and I hoped more projects would use this approach.
--
regards Helmut K. C. Tessarek
lookup http://sks.pkqs.net for KeyID 0xC11F128D
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
Re: [Patch] Simplifying mod_alias
Posted by Graham Leggett <mi...@sharp.fm>.
On 21 Dec 2014, at 4:18 PM, André Malo <nd...@perlig.de> wrote:
> I think, most of the directives are compatibility ones. IMHO the best way to
> handle a transition to a different configuration concept would be to
> introduce a new module (mod_alias_ng or mod_fs_map or so...) instead of
> patching the current one and producing a lot of anger (Alias* and Redirect*
> are often used in my experience, also in combination with proxy and rewrite
> stuff). Additionally this could serve as a kind of an A/B test to test your
> configuration (and see if people really like it, if anybody cares about
> that).
Just to clarify as I don’t think it has been made clear - none of the existing configurations have been changed or altered in any way, they work exactly the same way as before.
What has changed is that the Alias/Redirect/ScriptAlias now work inside a Location with one less argument. These combinations were rejected before with a syntax error.
This change brings Redirect/Alias/ScriptAlias in line with ProxyPass, and removes an arbitrary difference in the way the directives work.
What we should do in future is remove all the *Match directives and move them into a mod_alias_compat module, leaving just Alias/Redirect/ScriptAlias in mod_alias, same as we did with authnz in httpd v2.4.
Regards,
Graham
—
Re: [Patch] Simplifying mod_alias
Posted by André Malo <nd...@perlig.de>.
Hi,
I think, most of the directives are compatibility ones. IMHO the best way to
handle a transition to a different configuration concept would be to
introduce a new module (mod_alias_ng or mod_fs_map or so...) instead of
patching the current one and producing a lot of anger (Alias* and Redirect*
are often used in my experience, also in combination with proxy and rewrite
stuff). Additionally this could serve as a kind of an A/B test to test your
configuration (and see if people really like it, if anybody cares about
that).
nd
* Graham Leggett wrote:
> On 27 Jan 2014, at 12:11 AM, GRAHAM LEGGETT <mi...@sharp.fm> wrote:
> > A look at mod_alias shows it has 7 directives:
> >
> > • Alias
> > • AliasMatch
> > • Redirect
> > • RedirectMatch
> > • RedirectPermanent
> > • RedirectTemp
> > • ScriptAlias
> > • ScriptAliasMatch
> >
> > In theory we only need these three:
> >
> > • Alias
> > • Redirect
> > • ScriptAlias
> >
> > What I'm keen to do is enable expression support and deprecate all but
> > the above, with the following as the preferred configuration method
> > (same as the one used by ProxyPass):
> >
> > <Location /foo>
> > Alias /var/lib/bar
> > …stuff...
> > </Location>
> >
> > or
> >
> > <LocationMatch ^/foo/(?<bar>[^/]+)>
> > Alias /var/lib/%{env:MATCH_BAR}/baz
> > …stuff...
> > </LocationMatch>
> >
> > In theory this would be faster as we would not be scanning the list of
> > Aliases followed by the list of Locations each time, and things get a
> > lot simpler to use.
>
> This patch implements the above.
>
> The idea is that the existing syntaxes remain unaltered (and can be
> deprecated in future), while we introduce new Location syntaxes with a
> single argument, like so:
>
> <Location /image>
> Alias /ftp/pub/image
> </Location>
> <LocationMatch /error/(?<NUMBER>[0-9]+)>
> Alias /usr/local/apache/errors/%{env:MATCH_NUMBER}.html
> </LocationMatch>
> <Location /one>
> Redirect permanent http://example.com/two
> </Location>
> <Location /three>
> Redirect 303 http://example.com/other
> </Location>
> <LocationMatch /error/(?<NUMBER>[0-9]+)>
> Redirect permanent http://example.com/errors/%{env:MATCH_NUMBER}.html
> </LocationMatch>
> <Location /cgi-bin >
> ScriptAlias /web/cgi-bin/
> </Location>
> <LocationMatch /cgi-bin/errors/(?<NUMBER>[0-9]+)>
> ScriptAlias /web/cgi-bin/errors/%{env:MATCH_NUMBER}.cgi
> </LocationMatch>
>
> Big win: three fewer reasons to use mod_rewrite (and maybe
> mod_vhost_alias).
>
> Regards,
> Graham
> —
--
"Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3)"
-- aus einer Rezension
<http://pub.perlig.de/books.html#apache2>
Re: [Patch] Simplifying mod_alias
Posted by Tim Bannister <is...@c8h10n4o2.org.uk>.
On 21 Dec 2014, at 13:48, Graham Leggett <mi...@sharp.fm> wrote:
>
> This patch implements the above.
>
> The idea is that the existing syntaxes remain unaltered (and can be deprecated in future), while we introduce new Location syntaxes with a single argument, like so:
>
> <Location /image>
> Alias /ftp/pub/image
> </Location>
> <LocationMatch /error/(?<NUMBER>[0-9]+)>
> Alias /usr/local/apache/errors/%{env:MATCH_NUMBER}.html
> </LocationMatch>
> <Location /one>
> Redirect permanent http://example.com/two
> </Location>
> <Location /three>
> Redirect 303 http://example.com/other
> </Location>
> <LocationMatch /error/(?<NUMBER>[0-9]+)>
> Redirect permanent http://example.com/errors/%{env:MATCH_NUMBER}.html
> </LocationMatch>
> <Location /cgi-bin >
> ScriptAlias /web/cgi-bin/
> </Location>
> <LocationMatch /cgi-bin/errors/(?<NUMBER>[0-9]+)>
> ScriptAlias /web/cgi-bin/errors/%{env:MATCH_NUMBER}.cgi
> </LocationMatch>
This might look odd, though:
<Location /gone>
Redirect 410
</Location>
…so how about adding one new directive e.g. ForceStatus:
<Location /gone>
ForceStatus 410
</Location>
--
Tim Bannister – isoma@c8h10n4o2.org.uk
[Patch] Simplifying mod_alias
Posted by Graham Leggett <mi...@sharp.fm>.
On 27 Jan 2014, at 12:11 AM, GRAHAM LEGGETT <mi...@sharp.fm> wrote:
> A look at mod_alias shows it has 7 directives:
>
> • Alias
> • AliasMatch
> • Redirect
> • RedirectMatch
> • RedirectPermanent
> • RedirectTemp
> • ScriptAlias
> • ScriptAliasMatch
>
> In theory we only need these three:
>
> • Alias
> • Redirect
> • ScriptAlias
>
> What I'm keen to do is enable expression support and deprecate all but the above, with the following as the preferred configuration method (same as the one used by ProxyPass):
>
> <Location /foo>
> Alias /var/lib/bar
> …stuff...
> </Location>
>
> or
>
> <LocationMatch ^/foo/(?<bar>[^/]+)>
> Alias /var/lib/%{env:MATCH_BAR}/baz
> …stuff...
> </LocationMatch>
>
> In theory this would be faster as we would not be scanning the list of Aliases followed by the list of Locations each time, and things get a lot simpler to use.
This patch implements the above.
The idea is that the existing syntaxes remain unaltered (and can be deprecated in future), while we introduce new Location syntaxes with a single argument, like so:
<Location /image>
Alias /ftp/pub/image
</Location>
<LocationMatch /error/(?<NUMBER>[0-9]+)>
Alias /usr/local/apache/errors/%{env:MATCH_NUMBER}.html
</LocationMatch>
<Location /one>
Redirect permanent http://example.com/two
</Location>
<Location /three>
Redirect 303 http://example.com/other
</Location>
<LocationMatch /error/(?<NUMBER>[0-9]+)>
Redirect permanent http://example.com/errors/%{env:MATCH_NUMBER}.html
</LocationMatch>
<Location /cgi-bin >
ScriptAlias /web/cgi-bin/
</Location>
<LocationMatch /cgi-bin/errors/(?<NUMBER>[0-9]+)>
ScriptAlias /web/cgi-bin/errors/%{env:MATCH_NUMBER}.cgi
</LocationMatch>
Big win: three fewer reasons to use mod_rewrite (and maybe mod_vhost_alias).
Regards,
Graham
—
Re: Simplifying mod_alias
Posted by Kurt Newman <ku...@cpanel.net>.
> Thoughts?
In the long run, this would be a fantastic change, particularly from a support and automation perspective.
In the short run, conversion won't be fun. But that's what change does, and isn't unique to just this.
Thanks
Re: Simplifying mod_alias
Posted by Thomas Eckert <th...@gmail.com>.
> Why would they struggle any more than this, which is what they would need
to do for the same config today?
> AliasMatch ^/foo/(?<bar>[^/]+) /var/lib/${1}/baz
> <LocationMatch ^/foo/(?<bar>[^/]+)>
> …stuff...
> </LocationMatch>
I can't put my finger on it so I guess it's not much of an argument and
more of a gut feeling.
> One is a performance problem, which is a nice but not critical. The
second more important problem is that I am hearing from more and more
people that httpd has too many
> directives - they look at httpd and they don't know where to start.
I'm always +1 on the speed stuff and you also got a point there about the
number of directives. Overall there really are quite a lot. So cutting down
on them would probably make for a less scary environment for new users and
established ones as well.
I was going to write a novel worth of text but actually I think you are on
to something good :-)
On Mon, Jan 27, 2014 at 9:29 AM, Graham Leggett <mi...@sharp.fm> wrote:
> On 27 Jan 2014, at 9:58 AM, Thomas Eckert <th...@gmail.com>
> wrote:
>
> > When doing this please keep in mind there is a huge amount of users out
> there who are not developers and who will struggle with something like
> >
> > > <LocationMatch ^/foo/(?<bar>[^/]+)>
> > > Alias /var/lib/%{env:MATCH_BAR}/baz
> > > …stuff...
> > > </LocationMatch>
>
> Why would they struggle any more than this, which is what they would need
> to do for the same config today?
>
> AliasMatch ^/foo/(?<bar>[^/]+) /var/lib/${1}/baz
> <LocationMatch ^/foo/(?<bar>[^/]+)>
> …stuff...
> </LocationMatch>
>
> > As long as they are reusing the same code under the hood, I don't think
> there is anything wrong with having redundant directives whose only purpose
> is to have easier-to-read configurations.
>
> They're not reusing the same code under the hood, the code that performs
> the Location handling and the code that matches the Aliases are different
> code, and in today's code, the Alias is almost always followed by a
> Location directive matching the same URL space.
>
> That said there are two problems being solved here.
>
> One is a performance problem, which is a nice but not critical. The second
> more important problem is that I am hearing from more and more people that
> httpd has too many directives - they look at httpd and they don't know
> where to start.
>
> Existing configurations as I said will still work, they would just be
> deprecated. But the long term goal would be to remove the duplicated
> functionality and slim down the server, with a trimmer, cleaner server in a
> v3.x timeframe.
>
> Regards,
> Graham
> --
>
>
Re: Simplifying mod_alias
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1
On Jan 27, 2014, at 3:29 AM, Graham Leggett <mi...@sharp.fm> wrote:
> On 27 Jan 2014, at 9:58 AM, Thomas Eckert <th...@gmail.com> wrote:
>
>> When doing this please keep in mind there is a huge amount of users out there who are not developers and who will struggle with something like
>>
>>> <LocationMatch ^/foo/(?<bar>[^/]+)>
>>> Alias /var/lib/%{env:MATCH_BAR}/baz
>>> …stuff...
>>> </LocationMatch>
>
> Why would they struggle any more than this, which is what they would need to do for the same config today?
>
> AliasMatch ^/foo/(?<bar>[^/]+) /var/lib/${1}/baz
> <LocationMatch ^/foo/(?<bar>[^/]+)>
> …stuff...
> </LocationMatch>
>
>> As long as they are reusing the same code under the hood, I don't think there is anything wrong with having redundant directives whose only purpose is to have easier-to-read configurations.
>
> They're not reusing the same code under the hood, the code that performs the Location handling and the code that matches the Aliases are different code, and in today's code, the Alias is almost always followed by a Location directive matching the same URL space.
>
> That said there are two problems being solved here.
>
> One is a performance problem, which is a nice but not critical. The second more important problem is that I am hearing from more and more people that httpd has too many directives - they look at httpd and they don't know where to start.
>
> Existing configurations as I said will still work, they would just be deprecated. But the long term goal would be to remove the duplicated functionality and slim down the server, with a trimmer, cleaner server in a v3.x timeframe.
>
> Regards,
> Graham
> --
>
Re: Simplifying mod_alias
Posted by Graham Leggett <mi...@sharp.fm>.
On 27 Jan 2014, at 9:58 AM, Thomas Eckert <th...@gmail.com> wrote:
> When doing this please keep in mind there is a huge amount of users out there who are not developers and who will struggle with something like
>
> > <LocationMatch ^/foo/(?<bar>[^/]+)>
> > Alias /var/lib/%{env:MATCH_BAR}/baz
> > …stuff...
> > </LocationMatch>
Why would they struggle any more than this, which is what they would need to do for the same config today?
AliasMatch ^/foo/(?<bar>[^/]+) /var/lib/${1}/baz
<LocationMatch ^/foo/(?<bar>[^/]+)>
…stuff...
</LocationMatch>
> As long as they are reusing the same code under the hood, I don't think there is anything wrong with having redundant directives whose only purpose is to have easier-to-read configurations.
They're not reusing the same code under the hood, the code that performs the Location handling and the code that matches the Aliases are different code, and in today's code, the Alias is almost always followed by a Location directive matching the same URL space.
That said there are two problems being solved here.
One is a performance problem, which is a nice but not critical. The second more important problem is that I am hearing from more and more people that httpd has too many directives - they look at httpd and they don't know where to start.
Existing configurations as I said will still work, they would just be deprecated. But the long term goal would be to remove the duplicated functionality and slim down the server, with a trimmer, cleaner server in a v3.x timeframe.
Regards,
Graham
--
Re: Simplifying mod_alias
Posted by Thomas Eckert <th...@gmail.com>.
When doing this please keep in mind there is a huge amount of users out
there who are not developers and who will struggle with something like
> <LocationMatch ^/foo/(?<bar>[^/]+)>
> Alias /var/lib/%{env:MATCH_BAR}/baz
> …stuff...
> </LocationMatch>
As long as they are reusing the same code under the hood, I don't think
there is anything wrong with having redundant directives whose only purpose
is to have easier-to-read configurations.
On Sun, Jan 26, 2014 at 11:19 PM, Reindl Harald <h....@thelounge.net>wrote:
>
> Am 26.01.2014 23:11, schrieb Graham Leggett:
> > A look at mod_alias shows it has 7 directives:
> >
> > • Alias
> > • AliasMatch
> > • Redirect
> > • RedirectMatch
> > • RedirectPermanent
> > • RedirectTemp
> > • ScriptAlias
> > • ScriptAliasMatch
> >
> > In theory we only need these three:
> >
> > • Alias
> > • Redirect
> > • ScriptAlias
>
> in real world you would break existing configs like
>
> RedirectMatch 404 ^/.*setup/(.*)$
>
> without handle the non-Match directives also like expressions
> which changes behavior you can't remove Match
>
> however, admins will not appreciate such incompatible changes for no
> *real* good reason, even not in case of major upgrades
>
>
>
Re: Simplifying mod_alias
Posted by Reindl Harald <h....@thelounge.net>.
Am 26.01.2014 23:11, schrieb Graham Leggett:
> A look at mod_alias shows it has 7 directives:
>
> • Alias
> • AliasMatch
> • Redirect
> • RedirectMatch
> • RedirectPermanent
> • RedirectTemp
> • ScriptAlias
> • ScriptAliasMatch
>
> In theory we only need these three:
>
> • Alias
> • Redirect
> • ScriptAlias
in real world you would break existing configs like
RedirectMatch 404 ^/.*setup/(.*)$
without handle the non-Match directives also like expressions
which changes behavior you can't remove Match
however, admins will not appreciate such incompatible changes for no
*real* good reason, even not in case of major upgrades