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.
