rewrite rule from cgi to php

[blakmonk]

Hi,

I'm trying to write a RewriteRule that would redirect a .cgi to a .php, but apache does not like it.. How can I get arround to do that?

RewriteRule ^/cgi-bin/dir/scr1.cgi /var/www/html/dir2/scr2.php

I get an error saying that ExecCGI is not activated in the html directory.. if I add execcgi to the html directr, well it tries to execute the .php (and of coarse it does not start with #!/usr/bin/php.

How do I do that?

thnX
blakMonk

[coopster]

Welcome to WebmasterWorld, blakmonk!

Is this a permanent redirect?

[blakmonk]

Hi,

Thank you for the warm and quick welcome...

Yes, permanent redirect.

I want to do this redirect because I have a gazillion people (ok, not that many) accessing the cgi script, I don't want to have to call them all up and say "user this .php instead"

BlakMonk

[gergoe]

Try this one:

RewriteEngine on
RewriteRule ^/cgi-bin/dir/scr1.cgi http://www.domain.com/dir2/scr2.php [R=301,L]

Please note that depending on where you put the rewriting (httpd.conf or .htaccess file) you'll need to use a bit different pattern (the first part of the RewriteRule). If you use this one in yout httpd.conf, then it will be working well, but if you put it into a htaccess file in the root of your website (/var/www/html/) then you need to leave off the first slash. Check out the mod_rewrite documentation [httpd.apache.org] for further details of how the mod_rewrite is working in different setups.

[blakmonk]

Hi,

I have several questions about what you wrote;

R=301 : what does it do ( where can I find the list of the letters and what they do)?
L => I know it's stops the treatment of the rules.

I'm looking for something transparent and with local files.

I managed to put rewrite rules for virtual hosts that get the file paths from a map file. But for some reason I cannot find the rule to redirect a cgi script to a pho script.

BlakMonk

[coopster]

This should work.

In a per-directory override (.htaccess) file:

RewriteEngine on 
RewriteBase /cgi-bin/dir 
RewriteRule ^scr1\.cgi [example.com...]  [R=301,L]

Or, in httpd.conf:

RewriteEngine on 
RewriteRule ^/cgi-bin/dir/scr1\.cgi [example.com...]  [R=301,L]

The period (.) has special meaning in mod_rewrite regular expressions so it needs to be escaped.

R=301 : what does it do...
Permanent redirection.

...( where can I find the list of the letters and what they do)?
RewriteRule [httpd.apache.org]

...and the numbers here:
ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt

[gergoe]

I almost sent the same response as coopster did, so just two short comments here;
The . is not really significant in some regexes since it matches any single character, so it will match the . in the url also. This way the code is a bit more readable (and understandable for people not familiar with the regular expressions - imho). But indeed, use the

\.

to match a . char in the url, that's much safer, and more consequent.

I don't suggest you to try to "fake" a cgi executable with a php file, although it might be working, but it is just weird, so I think if you don't have any arguments against redirect then you'd be better of to redirect only. Is there some html forms somewhere which are using this cgi to post data to (not with the GET method, that can be forwarded with the redirect)?

<add>
The L flag means; this is the last rule, stop processing any further rewrites. You really don't need it if you have only one, but you never know... Let's dig yourself into the mod_rewrite documentation, to find out more about this, I'll assure you that you'll be amazed on it's power.
</add>

[blakmonk]

Hi guys,

I realy appreciate your help. But we are not quite there yet. I omited some information here they are.

I currently use mod_rewrte for virtual hosts. I use it in a .conf file that I include in httpd.conf. The rules use a map file that contains site and site_base_path.

everything works perfectly. But I'll add some L flags on some of the rules (thans for the link guys).

On of the scripts has a cgi script that is being accessed in two ways :

1- GET => blabla.com/cgi-bin/path/script1.cgi?var=value
2- POST => blabla.com/cgi-bin/path/script1.cgi

Now the problem :

I have rewriten the cgi script in php (way too heavy in perl, even with mod_perl). That and the fact that the modules I was abusing in perl did not all exist in php, I had to create the code myself, with lighter more specific code.

Now the users that access the script do not need to know and franckly most of them will take a awfull long time to do the url modification.

So my only option is to redirect/rewrite the blabla.com/cgi-bin/path/script1.cgi to blabla.com/path/script.php. All that in a way that the users keep accessing the .cgi script like they always did.

For that, you can see that I cannot use R=301 as it would return a code 301 to the application accessing the .cgi thus breaking whatever script that was calling my script.

Any ideas?

BlakMonk

[jdMorgan]

Earlier in the thread, you agreed that you wanted a permanent redirect, which is what a 301 redirect is. We'll just put that down to a misunderstanding of terms.

It seems to me that your problem is that, when redirecting a .cgi to a .php, Apache is still treating the file as executable, and that is the problem.

Can you turn off ExecCGI in part of your directory space, and move the php file into that area?

Jim

[blakmonk]

Oh yes, big missunderstanding from my end.

I already tried adding ExecCGI in the html/path/ where the script.php resides.. well, apache tries to execute the .php not interprate it.

I cannot remove ExecCGI from where the cgi is because thare other scripts in that directory being used by clients.

I've tried a lot of stuff before posting here, still stuck ... :(

BlakMonk

[gergoe]

If all the other options are gone, use the perls's built int http client to fetch the php file and put the content back to the browser. (use with caution, from the php you can't check remote addresses, referers or cookies anymore if you do it like this, unless you make your perl code very well)

[blakmonk]

Hi,

loading my php from perl is not an option, Just the fact of calling /usr/bin/perl for every request is too heavy. That i why I rewote everything in php.

BlakMonk

[gergoe]

Where you have placed the rewriting? Into a htaccess file? Could be that if you put it into your httpd.conf file, it might be working, because the processing of the htaccess files comes too late into the processing, so it might be that apache sets the file attribute to cgi (or something like this) and whatever you change it to, it still tries to process it as a perl script. See the explanation at the bottom of the RewriteBase directive documentation [httpd.apache.org].

[blakmonk]

Hi,

nope, everything is in the httpd.conf file

BlakMonk

[gergoe]

I have to disappoint you; I was curious about this, so I gave it a try (with Apache 1.3.27 on win32) and it was working perfectly. The request for the /cgi-bin/test.cgi returned the content of a php file from a directory other than the cgi-bin. Here're the settings I used:
The rewriting:

RewriteRule ^/cgi-bin/test.cgi$ /php.php[L]

/cgi-bin is a global (defined in httpd.conf) ScriptAlias for a directory, which haven't got any additional Options configured (not necessary since the ScripAlias does the job). The directory where the php file resides is a very common directory, does not have any options defined.

The most important is that I don't have any other rewriting for the directory, and not for the virtual server, this is the only one.

Which apache you are running?

[blakmonk]

Hi,

At this point, apache 1.3.27 on linux. But it will allso be running on apache 2.0.48.

I have several other rewrite rules for that set of virtuals. Here they are... maybe this will give you the same result I have. note, I did these 2 years ago, don't laugh too hard :)

Below you will see the content of the working rules . it uses a map file that contains lines like these:

www.blakmonk.com /virtuals/www.blakmonk.com

I stick the "RewriteRule ^/cgi-bin/dir/scr1.cgi /var/www/html/dir2/scr2.php" line in there, but no go...

------blak.conf
NameVirtualHost 192.168.15.100 NameVirtualHost 192.168.15.101
NameVirtualHost 192.168.15.102

<Directory /export/home/httpd/virtuels/*/cgi-bin>
Options FollowSymLinks ExecCGI
</Directory>

<VirtualHost 192.168.15.100 192.168.15.101 192.168.15.102 >
UseCanonicalName Off
RewriteEngine on

#- 4 hours 21600
CustomLog "¦/usr/sbin/rotatelogs /var/log/httpd/log.vblak 21600" vstuffed

RewriteMap lowercase int:tolower

RewriteMap vhost txt:/etc/httpd/conf/vblak.map

RewriteCond %{REQUEST_URI} !^/icons/
RewriteCond %{REQUEST_URI} !^/cgi-bin/
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$

RewriteCond ${vhost:%1} ^(/.*)$
RewriteCond %{REQUEST_URI} !^/cgi-bin/
RewriteRule ^/(.*)$ %1/html/$1

RewriteCond %{REQUEST_URI} ^/cgi-bin/
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$
RewriteCond ${vhost:%1} ^(/.*)$
RewriteRule ^/(.*)$ %1/$1 [T=application/x-httpd-cgi]

</VirtualHost>
-----

BlakMonk

[gergoe]

Where you have placed the (new) RewriteRule?
If it was in the beggining of the whole thing, then the it can screw up because you're checking the REQUEST_URI variable, which does not change if you rewrite the uri previously. Try changing the %{REQUEST_URI} to %{SCRIPT_FILENAME} in the RewriteConds.
If you've placed it after all these rules, then the problem might be because of the T flag, where you force the cgi mime type on every file in the cgi-bin directory, and regardless of the fact that you rewrite the cgi-bin to something else, the forced mimetype remains. Try adding the T=application/x-httpd-php flag to the (new) RewriteRule.

[blakmonk]

My target would be :
[...]
RewriteCond ${vhost:%1} ^(/.*)$
RewriteCond %{REQUEST_URI}!^/cgi-bin/
RewriteRule ^/(.*)$ %1/html/$1

---> Start HERE
RewriteCond %{SCRIPT_FILENAME} ^/cgi-bin/blak/blak.cgi
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$
RewriteCond ${vhost:%1} ^(/.*)$
RewriteRule ^/(.*)$ %1/html/blak/blak.php$1 [T=application/x-httpd-php]
----> End HERE

RewriteCond %{REQUEST_URI} ^/cgi-bin/
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$
RewriteCond ${vhost:%1} ^(/.*)$
RewriteRule ^/(.*)$ %1/$1 [T=application/x-httpd-cgi]

See, this i where I get confused.

BlakMonk

[gergoe]

You can do it like this also, but then don't forget to put the Last flag into the RewriteRule, otherwise your last rule will override it because of the difference between the REQUEST_URI and the SCRIPT_FILENAME variables I mentioned earlier. So give it a try with the L flag added, that should solve the problem.

Unfortunately I'm not much into linux, so I do not realy understand why the substitution string are seems to be an absuolute file system path (in the RewriteMap file), but I think you can leave out the virtualhosting related part for this newly added RewriteRule. Hopefully someone who's much more experienced with linux will give you some more hint on this.

<edit>oops, seems i posted this one before i could have it completed</edit>

[blakmonk]

Hi,

Sorry for the delai... The rules are not OS related so your knowledge is quite relevant.

I've tried a gazilion things.. still no luck...

Any idea where I can go to see the light?
(not the apache docs... i didn't find it in there)

</BlakMonk>

[gergoe]

My suggestion would be something like this:

[...][b]
RewriteRule ^/cgi-bin/blak/blak.cgi$ /blak/blak.php [NC]
[/b]
RewriteCond %{[b]SCRIPT_FILENAME[/b]}!^/icons/
RewriteCond %{[b]SCRIPT_FILENAME[/b]}!^/cgi-bin/
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$
RewriteCond ${vhost:%1} ^(/.*)$
RewriteRule ^/(.*)$ %1/html/$1 [b][L][/b]
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$
RewriteCond ${vhost:%1} ^(/.*)$
RewriteRule ^/cgi-bin/(.*)$ %1/cgi-bin/$1 [T=application/x-httpd-cgi]

This will rewrite the requests for [domain.com...] to [domain.com...] The second ruleset will translate the url into a local filesystem path, and the php file should be woking well, if you have the php configured properly.

[blakmonk]

Whoa!

It seems to work... Ok... it works on my dev server ( ok ok... my test workstation)...

I should be able to put that on the real server...

Man thank you soooooo much
If there's a way I can help you back in some way... let me know...

</BlakMonk>