Re: Patches to 1.3

[Dean Gaudet <dg...@arctic.org>]

On Wed, 2 Jul 1997, Alexei Kosut wrote:

> 1. I sent a patch to add AliasMatch, ScriptAliasMatch and RedirectMatch to
> mod_alias (enabling regex) and DirectoryMatch, FilesMatch and
> LocationMatch to http_core. There was sufficient interest in an earlier
> version of this patch that used a different syntax. Could I get a couple
> of +1s?

My complaint is that I'd rather see fewer directives with more powerful
operands.

> 2. I wondered if the default server root on Windows shouldn't be changed
> from "/usr/local/etc/httpd" (which is much more useful on Unix than
> Windows) to something like "/apache" (Marc commented that it should be
> lowercase, which I'll agree to). Does anyone want to complain about this?
> Otherwise, I'll just go ahead and commit it.

+0

Dean

Re: Patches to 1.3

[Alexei Kosut <ak...@organic.com>]

On Wed, 2 Jul 1997, Dean Gaudet wrote:

> On Wed, 2 Jul 1997, Alexei Kosut wrote:
> > If you perfer, don't think of Alias and AliasMatch as different
> > directives. Think of them as the same directive with different names.
> > (they are, really) And I personally feel that, given the current state of
> > Apache 1.x, this is the best solution that does not add confusion to the
> > server or require massive amounts of rewriting (like your approach) which
> > is best left for 2.0.
> 
> They don't add confusion because the confusion is already there :)  I'm

Sorry. The phrases were seperate. The "(like your approach)" modifed the
phrase after the or, not the one before it.

> not vetoing your patch or anything.  I'm just expressing one of the
> problems that needs solving.  It isn't right for every little bit of the
> config language to have a slightly different string matching mechanism. 
> Prefix match, postfix match, with or without leading ., yadda yadda... are
> all regular expressions. 

Again, I agree. I just think that this is best left for 2.0, and that the
approach taken by my patch is best, given the somewhat sorry state of
Apache 1.x configuration.

-- Alexei Kosut <ak...@organic.com>

Re: Patches to 1.3

[Dean Gaudet <dg...@arctic.org>]

On Wed, 2 Jul 1997, Alexei Kosut wrote:
> If you perfer, don't think of Alias and AliasMatch as different
> directives. Think of them as the same directive with different names.
> (they are, really) And I personally feel that, given the current state of
> Apache 1.x, this is the best solution that does not add confusion to the
> server or require massive amounts of rewriting (like your approach) which
> is best left for 2.0.

They don't add confusion because the confusion is already there :)  I'm
not vetoing your patch or anything.  I'm just expressing one of the
problems that needs solving.  It isn't right for every little bit of the
config language to have a slightly different string matching mechanism. 
Prefix match, postfix match, with or without leading ., yadda yadda... are
all regular expressions. 

Dean

Re: Patches to 1.3

[Alexei Kosut <ak...@organic.com>]

On Wed, 2 Jul 1997, Dean Gaudet wrote:

> No it doesn't have to be exactly the same as perl.  At any rate, here is
> essentially what I was thinking of:

[...]

> This then abstracts the concept of matching strings.  You need to define
> a syntax that the parser understands.  Then everything is switched to
> using this, and we can add to the syntax freely later should we need to.

This is well and good, but I honestly don't think it's all that useful for
the current Apache code, since nearly every place it matches strings, it
does it just a little bit differently. Which is why I suggested that for
2.0, it's a good idea. But if we want to keep 1.3 config files compatible
with 1.2 and earlier (which we do), it's not all that useful.

Some string matches in Apache are prefix matches, some are prefix matches
that have to match file segments. Some will match anywhere in the string.
Some are suffix matches. Some support shell-style metacharacters. Some
don't. And it's nearly impossible for such an abstraction to know exactly
what to do with Apache's various uses of match substitution.

In other words, I think this is far more complicated than you make it out
to be. My patch, on the other hand, is very simple. See below:

[...]

> At any rate your patch adds new directives without adding more
> functionality, right?  It can be accomplished with mod_rewrite
> already... why can't people just use mod_rewrite?  Of course, ad hoc
> is the tradition of the apache config language :)

No, I've spent the last year thinking about this, and have decided it's
the proper thing to do. mod_rewrite is not used by the vast majority of
Apache users, because it is very complex in nature. My *Match directives
are, on the other hand, simple. Even Ralf liked them, for that reason.

If you perfer, don't think of Alias and AliasMatch as different
directives. Think of them as the same directive with different names.
(they are, really) And I personally feel that, given the current state of
Apache 1.x, this is the best solution that does not add confusion to the
server or require massive amounts of rewriting (like your approach) which
is best left for 2.0.

-- Alexei Kosut <ak...@organic.com>

Re: Patches to 1.3

[Dean Gaudet <dg...@arctic.org>]

No it doesn't have to be exactly the same as perl.  At any rate, here is
essentially what I was thinking of:

typedef struct {
   blah blah;
} strmatch_t;

/* parse a single match-expression, storing whatever gunk is necessary in m
 * and advancing args past the end of the match-expression.  Return NULL if
 * no errors, otherwise return an error message describing the error found.
 */
char *parse_strmatch (pool *p, const char **args, strmatch_t **m);

/* run m against str, return whatever is appropriate */
int run_strmatch (pool *p, strmatch_t *m, const char *str);


This then abstracts the concept of matching strings.  You need to define
a syntax that the parser understands.  Then everything is switched to
using this, and we can add to the syntax freely later should we need to.

However see my recent message about <Directory> and the semantics of regexs
vs. wildcards vs. exact matches for an example where we'd need to peer
into the strmatch_t structure and break the abstraction.

At any rate, this is a start.

Another similar case that we shouldn't need to repeat code for, and
we should handle cleanly is +/- on any of the "bitfield" directives.
Such as DirectoryOptions, RewriteOptions, AllowOverride.  We already
have it for Options, it just needs to be abstracted.

At any rate your patch adds new directives without adding more
functionality, right?  It can be accomplished with mod_rewrite
already... why can't people just use mod_rewrite?  Of course, ad hoc
is the tradition of the apache config language :)

Dean

On Wed, 2 Jul 1997, Alexei Kosut wrote:

> On Wed, 2 Jul 1997, Dean Gaudet wrote:
> 
> > On Wed, 2 Jul 1997, Alexei Kosut wrote:
> > 
> > > 1. I sent a patch to add AliasMatch, ScriptAliasMatch and RedirectMatch to
> > > mod_alias (enabling regex) and DirectoryMatch, FilesMatch and
> > > LocationMatch to http_core. There was sufficient interest in an earlier
> > > version of this patch that used a different syntax. Could I get a couple
> > > of +1s?
> > 
> > My complaint is that I'd rather see fewer directives with more powerful
> > operands.
> 
> I don't think that's feasible for 1.3; the current configuration syntax is
> such that nothing really is all that coherent anyway, and I believe that
> "AliasMatch ..." is more readable and usable then anything that could be
> accomplished with "Alias ..." today. I do agree that for 2.0, this should
> be rethought. But I think this is the best solution for 1.x.
> 
> Some have suggested using Perl's /regex/options syntax. I have one
> question. How is this:
> 
> Alias /icons/
> 
> from this:
> 
> Alias /icons/
> 
> The first matches any request beginning with "/icons/". The second is a
> regular expression that matches any request that contains the string
> "icons" in it.
> 
> Mmm?
> 
> -- Alexei Kosut <ak...@organic.com>
> 
> 

Re: Patches to 1.3

[Alexei Kosut <ak...@organic.com>]

On Wed, 2 Jul 1997, Dean Gaudet wrote:

> On Wed, 2 Jul 1997, Alexei Kosut wrote:
> 
> > 1. I sent a patch to add AliasMatch, ScriptAliasMatch and RedirectMatch to
> > mod_alias (enabling regex) and DirectoryMatch, FilesMatch and
> > LocationMatch to http_core. There was sufficient interest in an earlier
> > version of this patch that used a different syntax. Could I get a couple
> > of +1s?
> 
> My complaint is that I'd rather see fewer directives with more powerful
> operands.

I don't think that's feasible for 1.3; the current configuration syntax is
such that nothing really is all that coherent anyway, and I believe that
"AliasMatch ..." is more readable and usable then anything that could be
accomplished with "Alias ..." today. I do agree that for 2.0, this should
be rethought. But I think this is the best solution for 1.x.

Some have suggested using Perl's /regex/options syntax. I have one
question. How is this:

Alias /icons/

from this:

Alias /icons/

The first matches any request beginning with "/icons/". The second is a
regular expression that matches any request that contains the string
"icons" in it.

Mmm?

-- Alexei Kosut <ak...@organic.com>