Re: Regex Help with Mod Rewrite
RewriteCond %{QUERY_STRING} ^(rain|spain|plain|,)+$
For a full explanation of what regex features are
and are not available, see the first result:
http://www.google.com/search?q=mod_rewritesourceid=mozillastart=0start=0ie=utf-8oe=utf-8
--
Ray B. Morris
[EMAIL PROTECTED]
Strongbox - The next generation in site security:
http://www.bettercgi.com/strongbox/
Throttlebox - Intelligent Bandwidth Control
http://www.bettercgi.com/throttlebox/
Strongbox / Throttlebox affiliate program:
http://www.bettercgi.com/affiliates/user/register.php
On 08/21/2007 11:04:58 AM, Soumya Sanyal wrote:
Hello,
This might not be the most appropriate forum to field this question -
but
I'm having serious issues with the formulation of a regex for Mod
Rewrite. I
actually have a couple of questions to ask :
1 What is particular flavor of the regex engine being used by Mod
Rewrite -
there are ever so slight variations in the different regex engines,
e.g.
linux grep vs perl grep etc.
2 I'm having trouble formulating a good compact regex to represent
the
following problem :
I want my RewriteCond to be conditioned on the %{QUERY_STRING} to
contain
only the powerset of a group of words e.g.
Hence if my set is say {rain,spain,plain}
The RewriteCond should say yes to the following :
http://foo.bar.com/?Operation=rain,spain
http://foo.bar.com/?Operation=plain,rain,rain
http://foo.bar.com/?Operation=plain,rain,spain
But not :
http://foo.bar.com/?Operation=rain,spain,mainly
Help please ?
Re: Regex Help with Mod Rewrite
Hi Soumya,
Yep, for the future you probably want the user support list (
http://httpd.apache.org/lists.html#http-users).
However, to be helpful I think the answers to your questions would be
1) Apache 1.3 uses POSIX based regular expressions, and apache 2.x uses the
PCRE library, so they're perl compatible.
2)
RewriteCond %{QUERY_STRING}
(^||;)Operation=(((rain|spain|plain),)*(rain|spain|plain))($||;)
RewriteRule . - [E=OPERATION:%2]
There are lots of ways to optimise the above, but I've kept it to something
relatively simple for easy reading...
If you wanted anything more complicated than that in a single rule, I'd
suggest looking at writing your own internal map function. This list could
help you with that.
HTH,
Ross Heritage.
On 21/8/07 17:04, Soumya Sanyal [EMAIL PROTECTED] wrote:
Hello,
This might not be the most appropriate forum to field this question - but
I'm having serious issues with the formulation of a regex for Mod Rewrite. I
actually have a couple of questions to ask :
1 What is particular flavor of the regex engine being used by Mod Rewrite -
there are ever so slight variations in the different regex engines, e.g.
linux grep vs perl grep etc.
2 I'm having trouble formulating a good compact regex to represent the
following problem :
I want my RewriteCond to be conditioned on the %{QUERY_STRING} to contain
only the powerset of a group of words e.g.
Hence if my set is say {rain,spain,plain}
The RewriteCond should say yes to the following :
http://foo.bar.com/?Operation=rain,spain
http://foo.bar.com/?Operation=plain,rain,rain
http://foo.bar.com/?Operation=plain,rain,spain
But not :
http://foo.bar.com/?Operation=rain,spain,mainly
Help please ?
Re: fixing graceful-stop with event mpm
On Mon, Aug 20, 2007 at 04:00:48PM -0700, Paul Querna wrote: Short: We need to call ap_close_listeners() earlier or more aggressively. Question: Where/How? Looking at the Event MPM in both trunk and 2.2.x, the listener_thread is where we call ap_close_listeners(). This does not seem to be working quickly enough, per PR 43081: http://issues.apache.org/bugzilla/show_bug.cgi?id=43081 Crap :( When I test it on my linux box, it works for me, it's pretty fast, I'm guessing I have the wrong sort of load to see this, any idea how to replicate? I haven't quite got my head around how the listener thread is apparently blocking for so long, but I can't figure out another way that the listeners would stay online for so long either. The listener thread isn't neccessarily the only thread with a copy of the fd, I remember cgid catching me out before (which I fixed iirc). Solution: Add call to ap_close_listeners() in wakeup_listener(). I think this would pop out all of the listening sockets quickly from the listener pollset. How would you signal it? Solution: Actually start working on 3.0 with a sane event/start/shutdown model? That'd be nice alright :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: And 2.2.6 Re: Notice of Intent: TR 2.0.61
Hi, The fact that the apr_proc* API is so horribly convoluted yet still broken on Win32 is kind of ironic. If it's not fixable can we just abandon it? The code to implement piped loggers can be much simpler and more efficient on Unix if implemented natively. may I ask a question on this topic: why is piped logging so important, and why dont we add f.e. mod_log_rotate which does the job of rotating logs more nicerly on every platform? That would avoid 95% usage of piped logging: http://www.hexten.net/wiki/index.php/Mod-log-rotate sure, maybe there are other implementations like mysqllog or pgsqllog, and such which use piped logging; however I've tried already a lot, and none of all these 'solutions' work really reliable... Guen.
Re: And 2.2.6 Re: Notice of Intent: TR 2.0.61
Guenter Knauf wrote: may I ask a question on this topic: why is piped logging so important, and why dont we add f.e. mod_log_rotate which does the job of rotating logs more nicerly on every platform? That would avoid 95% usage of piped logging: http://www.hexten.net/wiki/index.php/Mod-log-rotate piped logging enables rotation for any kind of log file (at least log files of the modules that use the piped logging API). Examples: - SSL log - rewrite log - mod_jk log So it's not only about access logging. sure, maybe there are other implementations like mysqllog or pgsqllog, and such which use piped logging; however I've tried already a lot, and none of all these 'solutions' work really reliable... Guen. Regards, Rainer
Re: fixing graceful-stop with event mpm
On Aug 20, 2007, at 7:00 PM, Paul Querna wrote: Short: We need to call ap_close_listeners() earlier or more aggressively. Question: Where/How? Looking at the Event MPM in both trunk and 2.2.x, the listener_thread is where we call ap_close_listeners(). This does not seem to be working quickly enough, per PR 43081: http://issues.apache.org/bugzilla/show_bug.cgi?id=43081 I haven't quite got my head around how the listener thread is apparently blocking for so long, but I can't figure out another way that the listeners would stay online for so long either. Solution: Add call to ap_close_listeners() in wakeup_listener(). I think this would pop out all of the listening sockets quickly from the listener pollset. I've been wondering for awhile whether having the listener thread in event handle both initial connections as well as keepalives really makes sense, and whether breaking them out as 2 distinct threads might be better... One reason is that this would make it easier to create parity between worker and event on simple cases... This wouldn't completely solve the problem but it would isolate it to just the keepalive thread, making it easier I think to solve... But other than some very rough ideas on how to do it, I haven't really looked further.
auth dbd pgsql issues
Dear Experts, I am trying to track down a broken postgresql authn issue which I have described here: http://marc.info/?l=apache-httpd-usersm=118765132424174w=2 My guess is that I'm encountering the known issues with DBD described here: http://marc.info/?l=apache-httpd-devm=116742014418304w=2 Am I right in thinking that this is fixed in the trunk but not in 2.2.4? What about 2.2.5/6 - I don't see anything in the 2.2.5 changelog. Anyway, I have been looking at the source, and a few issues thoughts have occurred to me: - In mod_authn_dbd.c, a couple of global variables are used to point to the dbd_acquire and dbd_prepare functions. Am I right in thinking that this means you can have only one dbd driver for authn? So you can't for example, have postgresql in one virtual host and mysql in another? (Is this already a limitation of dbd?) This isn't a problem for me, unless these variables get set to NULL by a virtual host with no DBDriver directive. Maybe DBDriver should only appear in the global configuration? Is it certain that these variables are set before the server first forks? - It looks as if, when a new db connection is created, all prepared statements are prepared on the new connection. However, when a new prepared statement is created, it is not prepared on any existing connections. This is fine as long as all prepared statements are declared before any connections are established. Correct? - authn_dbd_password() uses the error message Error looking up %s in database for 3 different errors. It would be really great to have different messages in each case. - The mod_authn_dbd docs (http://httpd.apache.org/docs/2.2/mod/mod_authn_dbd.html) claim DBD drivers recognise both stdio-like %s and native syntax. Is this accurate? It seems that the postgresql DBD driver does some type magic based on the character after the %, which wouldn't be possible with the postgresql $1 syntax. Maybe $1 only works for strings (which would be OK for usernames, of course). (Does it correctly count the number of parameters if I use $1?) - The mod_dbd docs (http://httpd.apache.org/docs/2.2/mod/mod_dbd.html) say that DBDPersist can be 0 or 1; this should be on or off. Many thanks for any feedback. If the answer is this is fixed in 2.2.6, and that's due soon, I'll just wait. Regards, Phil.
mod_log_config cookie buglet
hi all :)
a co-worker and I were just adding some functionality to an internal
httpd module when we noticed that mod_log_config misbehaves when logging
cookie values...
in short, we have a cookie FOO and were adding a cookie CLIENT_FOO. in
the log format we used
%{FOO}C\t%{CLIENT_FOO}C
but the log spit out FOO for both values. yucko.
it turns out to be mod_log_config's log_cookie() function, where
ap_strstr_c() is used to find the cookie names. it seems that whichever
cookie is first in the incoming header is the one that gets logged,
provided that the name of one cookie is contained in the name of another.
anyway, I guess this bug has been around forever (though I haven't
looked beyond 2.2) but I have a feeling it's gone unnoticed because
people might expect similar values for similarly named cookies. in our
case, FOO was a decrypted version of CLIENT_FOO so the results were
radically different in format and the bug was immediately visible
(though not immediately obvious in source :)
anyway, sorry we don't have a patch for you :)
--Geoff
(who isn't subscribed anymore, so please CC me :)
Re: auth dbd pgsql issues
Phil Endecott wrote: http://marc.info/?l=apache-httpd-usersm=118765132424174w=2 My guess is that I'm encountering the known issues with DBD described here: http://marc.info/?l=apache-httpd-devm=116742014418304w=2 Am I right in thinking that this is fixed in the trunk but not in 2.2.4? What about 2.2.5/6 - I don't see anything in the 2.2.5 changelog. I think you're right about the problem you're encountering; the patches for 2.2.x await a third vote and so they're not in expected in 2.2.5/6, as it stands at the moment. - In mod_authn_dbd.c, a couple of global variables are used to point to the dbd_acquire and dbd_prepare functions. Am I right in thinking that this means you can have only one dbd driver for authn? So you can't for example, have postgresql in one virtual host and mysql in another? This shouldn't limit the use of multiple drivers (if you're using the mod_dbd from trunk). These mod_authn_dbd globals just point to common mod_dbd functions. Assuming there are no underlying incompatibilities between the drivers (or other bugs), mod_dbd's functions should invoke the relevant one's functions for each request. - It looks as if, when a new db connection is created, all prepared statements are prepared on the new connection. However, when a new prepared statement is created, it is not prepared on any existing connections. This is fine as long as all prepared statements are declared before any connections are established. Correct? Yes. The ap_dbd_prepare() statement must be used during the configuration phase only. The trunk code says: /* Prepare a statement for use by a client module during * the server startup/configuration phase. Can't be called * after the server has created its children (use apr_dbd_*). */ - authn_dbd_password() uses the error message Error looking up %s in database for 3 different errors. It would be really great to have different messages in each case. I'd suggest opening a Bugzilla report and, if possible, attaching a patch file with the revised messages you'd like to see (and please add the keyword PatchAvailable in this case). - The mod_authn_dbd docs (http://httpd.apache.org/docs/2.2/mod/mod_authn_dbd.html) claim DBD drivers recognise both stdio-like %s and native syntax. Is this accurate? It seems that the postgresql DBD driver does some type magic based on the character after the %, which wouldn't be possible with the postgresql $1 syntax. Maybe $1 only works for strings (which would be OK for usernames, of course). (Does it correctly count the number of parameters if I use $1?) I seem to recall some type magic in this driver, but I'm not particularly familiar with it. If you encounter problems, I'd again suggest opening a Bugzilla report. - The mod_dbd docs (http://httpd.apache.org/docs/2.2/mod/mod_dbd.html) say that DBDPersist can be 0 or 1; this should be on or off. I'll try to remember to fix that, but if you don't see it in trunk's docs after a while ... submit a Bugzilla report! :-) Thanks, Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
2.2.5
Hello. I just wonder if someone could tell me if and official 2.2.5/2.2.6 will be released before September the 10th? That's the version freeze date for Mandriva Linux 2008. Thanks in advance. -- Regards // Oden Eriksson
Re: 2.2.5
No guarantees, but the expectation is Yes, 2.2.6 will be released way before then. We're justing waiting for some APR cleanups before I tag/roll 2.2.6 On Aug 21, 2007, at 2:13 PM, Oden Eriksson wrote: Hello. I just wonder if someone could tell me if and official 2.2.5/2.2.6 will be released before September the 10th? That's the version freeze date for Mandriva Linux 2008. Thanks in advance. -- Regards // Oden Eriksson
Re: 2.2.5
tisdagen den 21 augusti 2007 skrev Jim Jagielski: No guarantees, but the expectation is Yes, 2.2.6 will be released way before then. We're justing waiting for some APR cleanups before I tag/roll 2.2.6 Thanks!. Sounds great! On Aug 21, 2007, at 2:13 PM, Oden Eriksson wrote: Hello. I just wonder if someone could tell me if and official 2.2.5/2.2.6 will be released before September the 10th? That's the version freeze date for Mandriva Linux 2008. Thanks in advance. -- Regards // Oden Eriksson -- Regards // Oden Eriksson
Re: auth dbd pgsql issues
Hi Chris, I think you're right about the problem you're encountering; the patches for 2.2.x await a third vote and so they're not in expected in 2.2.5/6, as it stands at the moment. I think you would increase chance for another vote if there would be only _one_ patch which applies cleanly against current 2.2.x head; I've started testing with them, but got stopped since one patch didnt apply of them all; therefore I only voted on the first one which I could test. If possible please create a new diff which includes all changes, and you get my vote at once after I have verified that at least some of the issues I see on threaded NetWare are gone with the patch (which I believe from what I've read so far)... thanks, Guen.
Re: svn commit: r568322 - /httpd/httpd/trunk/server/log.c
[EMAIL PROTECTED] wrote: Author: wrowe Date: Tue Aug 21 16:21:44 2007 New Revision: 568322 URL: http://svn.apache.org/viewvc?rev=568322view=rev Log: This message was confusing during debugging, make it unique. As you'd noticed, I've begun committing easily digestible pieces of the piped log bug fixes. I have a ways to go before all of the related patches are in (I'm trying to get this trimmed down to the bare minimum) but I'll holler once they are done. Oh - and I'm not committing anything out of sequence, it should be ready to validate at any point you want to check out. But the patches to httpd so far affect any platform, the patches to apr for windows are still coming (no flaws yet discovered in unix threadproc or file_io)
