I thought about this few times - it's a good idea but a bit scary ( the build process ), and not sure if a general regexp will work as well on the simple patterns we have.
On the other side most regexp impl. use finite machines and many optimizations - so they may be much faster. I'm +1 if you can do it first in an 'optional' way - like a separate module that can be excluded and will be used based on some option. It may need some hooks. If you want to start on this, I would propose we branch the code for a stable 1.0 release. My current thinking is to use 4.1.9 ( or whatever is the stable release) as a tag for jk1.2 'stable' and jk2 'beta'. Costin On Fri, 09 Aug 2002 04:07:27 -0700, Mladen Turk wrote: > Hi, > > Remember the last month advanced URI space resolution I proposed? > > Well, I've been working on that for a week or so, and found myself doing > things that are more or less regular expression matching of request uri. > Even existing uri_map code has a trace of that (matching star for > example), so IMO (since we are matching things) we could use the regex > code as a general uri->file space matching solution. That way the users > will be able to use the same syntax as for the <LocationMatch > or > mod_proxy, allowing one to make complex uri resolutions, like TRUE/FALSE > cases. > > The major drawback of that is that we'll need the pcre library, either > one that comes with the Apache 2 (by Philip Hazel) or Apache 1.3 (by > Henry Spencer). Since the same should be used with the IIS and other > platforms, I suggest that we use the one from Apache 2.0. > > Using pcre will introduce the need for build process changes (only 2.0 > can use the proposed pcre from its own build) and we'll need the > pcre.lib. > > Thoughts? > > MT. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
