RE: uri_map using regex [WAS: mod_jk, mod_jk2 URI spaces]
-Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 10, 2002 2:04 AM To: Tomcat Dev List Subject: Re: uri_map using regex [WAS: mod_jk, mod_jk2 URI spaces] Doesn't mod_rewrite do what you want here? In combination with mod_proxy, it can rewrite URL to URL as well, so you can get the resulting URL back in mod_jk and then just use normal mappings. Or maybe I'm on a totally wrong track here... True (I think) for the positive assertions, but: [uri:/examples/*] #matches entire app [uri:/examples/(?!\.(gif|jpe?g|png)$)] #matches everything except .gif, .jpg, .jpeg, .png The entire purpose is to be able to _disallow_ certain mappings in the already mapped application. I'm afraid that the mod_proxy cannot be used for such a thing, cause the first mapping will forcibly drive all the examples context through the TC. At first I was trying (before the pcre idea) to use the simple matching like : [uri:/examples/*] [uri:!/examples/*.jpg] ...etc This is can be parsed without using pcre (using apr_fnmatch), but what about more complex schemas involving directories and file extensions, not only files. On the other hand, we can use the mod_rewrite/mod_proxy only with the Apache, and we want to be portable thought. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: uri_map using regex [WAS: mod_jk, mod_jk2 URI spaces]
I think I understand what you're saying here and it will probably be necessary for non-Apache web servers anyway. I was thinking more along the lines of: 1. Anything you want to disallow for TC, rewrite to Apache visible filenames and/or URL's (in your example, image files). Apache will then happily serve them. 2. Anything else, rewrite to URL that match something that's in mod_jk's space. Bojan On Sat, 2002-08-10 at 16:31, Mladen Turk wrote: -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 10, 2002 2:04 AM To: Tomcat Dev List Subject: Re: uri_map using regex [WAS: mod_jk, mod_jk2 URI spaces] Doesn't mod_rewrite do what you want here? In combination with mod_proxy, it can rewrite URL to URL as well, so you can get the resulting URL back in mod_jk and then just use normal mappings. Or maybe I'm on a totally wrong track here... True (I think) for the positive assertions, but: [uri:/examples/*] #matches entire app [uri:/examples/(?!\.(gif|jpe?g|png)$)] #matches everything except .gif, .jpg, .jpeg, .png The entire purpose is to be able to _disallow_ certain mappings in the already mapped application. I'm afraid that the mod_proxy cannot be used for such a thing, cause the first mapping will forcibly drive all the examples context through the TC. At first I was trying (before the pcre idea) to use the simple matching like : [uri:/examples/*] [uri:!/examples/*.jpg] ...etc This is can be parsed without using pcre (using apr_fnmatch), but what about more complex schemas involving directories and file extensions, not only files. On the other hand, we can use the mod_rewrite/mod_proxy only with the Apache, and we want to be portable thought. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: uri_map using regex [WAS: mod_jk, mod_jk2 URI spaces]
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]
RE: uri_map using regex [WAS: mod_jk, mod_jk2 URI spaces]
From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Costin Manolache I thought about this few times - it's a good idea but a bit scary ( the build process ) The easiest would be if the guys from Apache 2 move the regex to the apr-util (I already make the question about that on the apr-dev). Apache 2 builds should be relatively easy to implement since we have the pcrelib already there. For the rest of the servers (IIS) we have the .dsp and all that is needed is to include that in the module build. and not sure if a general regexp will work as well on the simple patterns we have. Well everything is precompiled, so the performance shouldn't be an issue here. 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. I was planning to do that any way since this has lot of implications to the existing mappings, moving the new code to the jk_uriMapX.c and keeping function naming as is. 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'. Ok. That would be fine with me. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: uri_map using regex [WAS: mod_jk, mod_jk2 URI spaces]
Doesn't mod_rewrite do what you want here? In combination with mod_proxy, it can rewrite URL to URL as well, so you can get the resulting URL back in mod_jk and then just use normal mappings. Or maybe I'm on a totally wrong track here... As for IIS, dunno, don't care ;-) Bojan On Fri, 2002-08-09 at 21:07, 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
