Forum Moderators: phranque

Message Too Old, No Replies

Need Help with Perl Expression

Perl Expression causing syntax error in Apache 2.2.13

         

rescueme

9:12 pm on Jan 12, 2010 (gmt 0)

10+ Year Member



Hello,

We had been using Apache 2.2.6 and upgraded today to 2.2.13.

Now, a Perl expression we need in our Config file has been generating a Syntax Error and Apache will not longer launch, so all of our websites are down.

This is the Perl Expression which we use for a custom CGI on our server:

FastCgiExternalServer /Library/Tenon/WebServer/WebSites/.*(?<!\.(?:txtŠicoŠjpgŠgif))$ -re -host localhost:9008 -pass-header Authorization

The older version of Apache (2.2.6) had no problem with this, but the new version (2.2.13) apparently finds a syntax error in it. Any suggestions would be very, very appreciated!

Sincerely,

Jeff Gold

g1smd

11:02 pm on Jan 12, 2010 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month




I don't know what it should be, but I suspect a problem here...

.*(?<!\.(?:

I don't like the

.*
or
?:
parts, and I don't quite know what the
?<!
part does.

jdMorgan

11:19 pm on Jan 12, 2010 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Simplify the regex by dumping the 'greediness-control' tokens, and see if that helps:

FastCgiExternalServer /Library/Tenon/WebServer/WebSites/.+\.(gifŠjpgŠicoŠtxt)$

The next step would be to replace them with something a little more efficient than that simple version, but a little more portable than what you had originally:

FastCgiExternalServer /Library/Tenon/WebServer/WebSites/([^.]*\.)+(gifŠjpgŠicoŠtxt)$

This will be more efficient than the first code in this post if lots of your URL-paths have embedded periods in the "directory-path-part" or if they have more than one period in the "filename" path-part -- which I presume to be the reason for the originally-complicated pattern.

Note also the re-arrangement of the filetypes to most-frequently-accessed-first (tweak if your stats indicated otherwise).

Important: Replace all broken pipe "Š" characters above with solid pipes before use; Posting on this forum modifies the pipe characters.

Finally, when you get an error, check your server error log -- It often contains some very useful info.

Jim

rescueme

12:30 am on Jan 13, 2010 (gmt 0)

10+ Year Member



Thanks for the tips. The goal of this line is to simply send all web pages to our cgi EXCEPT those which end in .gif .jpg .ico or .txt

The other part, which I think was tricky initially when someone came up with this line for us, is that it must also send all pages to the cgi that contain no periods at all.

This way we can use simple names for all of our web pages, e.g.

www.somedomainname.com/filename
instead of filename.htm or filename.html etc.

As far as I know, we have no paths which contain periods (.) or filenames which contain more than the one period before the suffix. Based upon this explanation, what do you think is the simplest string we can use?

I assume I still append the following to the end of what you suggest?

-re -host localhost:9008 -pass-header Authorization

I looked in logs/error_log and didn't see any error message there. The syntax error message regarding this line only came up in the "iTools" program which we use to manage our server when it tried to launch Apache.

I temporarily downgraded our server software, but when I get some free time later will try upgrading again and using whatever you recommend based upon this clarified posting.

Hopefully we can use this newer version of Apache because of some security holes we need plugged.

Best wishes,

- Jeff

jdMorgan

3:31 am on Jan 13, 2010 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Hrmmm... Yes, when I got some time, I went and looked up that regex subpattern, and it's basically a negative look-behind saying "match "$" end-of-string NOT preceded by .gif. jpg, etc."

If the regex package installed on the problematic server doesn't support this level of regular-expressions (or if it's been compiled to leave out that support), then you won't be able to use the blah-blah-blah-NOT-blah type of pattern, and instead will have to specify what you DO want to send to the back-end using a pattern-match that is entirely-positive.

Given only your cursory description, of "no periods in our URL-paths" (otherwise know as "extensionless URLs"), then perhaps something like

FastCgiExternalServer /Library/Tenon/WebServer/WebSites/[0-9A-Za-z_]+$ -re -host localhost:9008 -pass-header Authorization

would work, or you might be able to use [\w]+$ instead of [0-9A-Za-z_]+$ on the end there.

If the back-end paths may contain subdirectories, then put a slash into the square-bracketed groups, making them [0-9A-Za-z_/]+ and [\w/]+ respectively.

Check your back-end filepaths carefully, and look for exceptions that contain anything except those specific characters. If you find a few more characters (hyphens, perhaps?) that need to be included, then do so. But if there are many exceptions that won't match this positive-match pattern and so many that you cannot simply add them as a short list of specific additional "FastCgiExternalServer" directives, then some other approach is likely needed.

If it's not already clear, support for various 'levels' of regular expressions varies, from POSIX regex on Apache1.x to various levels of PCRE (PERL-Compatible Regular Expressions) on Apache 2.x. One reason I always post code here using the older POSIX form is so we don't have to post three different versions of the code snippets for all of these various extended 'dialects' of regex...

So far, I've assumed that this is a problem with the regex pattern itself. But none of the documents that I've looked at mention the "-re" flag on this directive, and I'm not a fastcgi user myself. So I'm also assuming that that flag means "accept regular expressions in filepath" but I can't be sure...

Jim

rescueme

10:10 pm on Jan 13, 2010 (gmt 0)

10+ Year Member



Hi everyone,

Thanks for trying to help.

As it turns out, the company we got the updated Apache from put in a version of the FastCgi module which was incompatible with our CGI. So it had nothing to do with the script in the first place.

After re-installing the old module, everything is working again.

Best wishes,

- Jeff