httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: Patches to 1.3
Date Thu, 03 Jul 1997 00:17:47 GMT
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 :)


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 <>

View raw message