Re: [Patch] Simplifying mod_alias
On 31 Dec 2014, at 5:56 PM, Eric Covener cove...@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
On 22 Dec 2014, at 2:24 PM, Eric Covener cove...@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
On Wed, Dec 31, 2014 at 8:57 AM, Graham Leggett minf...@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
On Wed, Dec 31, 2014 at 8:57 AM, Graham Leggett minf...@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
On 31 Dec 2014, at 5:12 PM, Eric Covener cove...@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
On Wed, Dec 31, 2014 at 10:30 AM, Graham Leggett minf...@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
On 12/21/2014 02:48 PM, Graham Leggett wrote: On 27 Jan 2014, at 12:11 AM, GRAHAM LEGGETT minf...@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
On 21 Dec 2014, at 10:48 PM, Eric Covener cove...@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
On Mon, Dec 22, 2014 at 5:15 AM, Graham Leggett minf...@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
Am 22.12.2014 um 11:15 schrieb Graham Leggett: On 21 Dec 2014, at 10:48 PM, Eric Covener cove...@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 signature.asc Description: OpenPGP digital signature
Re: [Patch] Simplifying mod_alias
On 22 Dec 2014, at 14:53, Reindl Harald h.rei...@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
Am 22.12.2014 um 14:26 schrieb Graham Leggett: On 22 Dec 2014, at 14:53, Reindl Harald h.rei...@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 signature.asc Description: OpenPGP digital signature
[Patch] Simplifying mod_alias
On 27 Jan 2014, at 12:11 AM, GRAHAM LEGGETT minf...@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 — httpd-mod_alias-expr.patch Description: Binary data httpd-mod_alias-expr-test.patch Description: Binary data
Re: [Patch] Simplifying mod_alias
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 minf...@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
On 21 Dec 2014, at 4:18 PM, André Malo n...@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
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
On 21 Dec 2014, at 13:48, Graham Leggett minf...@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 – is...@c8h10n4o2.org.uk
Re: [Patch] Simplifying mod_alias
On Sun, Dec 21, 2014 at 9:41 AM, Graham Leggett minf...@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
On 21 Dec 2014, at 7:37 PM, Eric Covener cove...@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
On Sun, Dec 21, 2014 at 1:57 PM, Graham Leggett minf...@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: Simplifying mod_alias
On 27 Jan 2014, at 9:58 AM, Thomas Eckert thomas.r.w.eck...@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
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 minf...@sharp.fm wrote: On 27 Jan 2014, at 9:58 AM, Thomas Eckert thomas.r.w.eck...@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
+1 On Jan 27, 2014, at 3:29 AM, Graham Leggett minf...@sharp.fm wrote: On 27 Jan 2014, at 9:58 AM, Thomas Eckert thomas.r.w.eck...@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
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
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: Simplifying mod_alias
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 signature.asc Description: OpenPGP digital signature
Re: Simplifying mod_alias
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.rei...@thelounge.netwrote: 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