Forum Moderators: phranque

Message Too Old, No Replies

RewriteCond not catching the condition

files in cgi-bin don't match condition?

         

Philosopher

5:03 pm on Nov 19, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I have a few sites that run via Joomla using SEF URLs (search engine friendly).

The basic .htaccess commands used to create SEF URLs are

RewriteCond %{REQUEST_FILENAME}!-f
RewriteCond %{REQUEST_FILENAME}!-d
RewriteRule ^(.*) index.php

Easy enough...The commands basically state if the requested filename isn't a file or directory, then process the rewrite rule.

The way the CMS is setup, if a file that does not exist and does not match any Joomla content is requested, it is redirected back to the homepage (I know not ideal, but it's not a big deal with these sites).

Anyway, now I need to incorporate another script into this setup. This script resides in the cgi-bin.

For some reason, when I place a file, any file into the cgi-bin, the above RewriteCond statements fail. By that I mean, if I try and access them such as

http://www.example.com/cgi-bin/myscript.cgi

It automatically gets the 301 redirect back to the homepage as if the file didn't exist.

If I place the file anywhere else in the public_html folder except for the cgi-bin, I can access it fine, but as soon as a file, any file is placed inside the cgi-bin, the redirect kicks in.

What is it about the cgi-bin that is causing these Conditions to fail?

Marcia

5:37 pm on Nov 19, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



If I place the file anywhere else in the public_html folder except for the cgi-bin, I can access it fine

If you can access it (assuming it's with a browser), then so can anyone else, including those with malicious intentions looking for holes.

but as soon as a file, any file is placed inside the cgi-bin, the redirect kicks in.

What is it about the cgi-bin that is causing these Conditions to fail?


Permissions for the folder, maybe? And do you really want anyone to be able to view your executables, regardless of their intentions?

Philosopher

5:42 pm on Nov 19, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Marcia,

I don't think you quite understand. You NEED to be able to access files in the cgi-bin.

Not read them, but access and execute them. That's what the cgi-bin is for, to place executable files in (scripts).

The problem is, when I try and access them (read, "execute") the RewriteRule is kicking in even though the RewriteCond statements should not allow it to get that far.

Marcia

6:00 pm on Nov 19, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



>I don't think you quite understand.

Right, I did misunderstand. I thought what was meant was being able to view them in the browser.

Philosopher

6:04 pm on Nov 19, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Noooo...don't want that. :)

Thanks for trying to help though.

Philosopher

9:01 pm on Nov 19, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I've done some additional searching and found this seems to be a somewhat common problem with various CMS systems out there.

Unfortunatley, while I've found a number of postings in various places from people having this problem, I have yet to find a posting about solving it. :(

Any help would be appreciated!

jdMorgan

10:00 pm on Nov 19, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



The code you posted above doesn't generate a redirect, it does an internal rewrite. So where is this redirect done?

Jim

Philosopher

11:14 pm on Nov 19, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Correct. The code posted simply rewrites the request to the index.php file.

The SEF module has a section of code that handles the actual 301 redirect. Basically, it looks to see if the page name matches a component or content item of the CMS. If not, it issues the 301 to the homepage.

The thing is, unless I'm not understanding something, it shouldn't even get that far. The RewriteCond should see that the cgi-bin request is a file and skip the RewriteRule shouldn't it?

jdMorgan

11:43 pm on Nov 19, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



That depends on how the /cgi-bin folder is implemented. If it's Aliased to a different location than its URL would appear to locate it, then that Alias may kick in before the Rule can be applied. On the other hand, have you tried adding a RewriteCond to stop the rule being invoked for /cgi-bin requests, such as

RewriteCond %{REQUEST_URI} !^/cgi-bin/

Or if I'm misunderstanding your goal and have it backwards, have you tried copying the rule-set into the cgi-bin directory itself, or even just putting an .htaccess file in /cgi-bin containing the line

RewriteOptions Inherit

Basically, hosts sometimes do 'funny' things with cgi-bin directories, and one of these things may be affecting your rule invocation.

Jim

Philosopher

12:28 am on Nov 20, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Hi Jim,

I have tried adding the RewriteCond you suggested previously and I am still getting the same results regardless of whether that line is added to the htaccess or not.

I also tried adding the "RewriteOptions Inherit" command you suggested with no luck.

Any other ideas? Thanks!

It shouldn't be this difficult to get one little thing to work! :)

Philosopher

6:43 pm on Nov 20, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



*Bump*

Any new ideas?

jdMorgan

8:46 pm on Nov 20, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Did you try the other suggestion yet?

Jim

Philosopher

9:06 pm on Nov 20, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Hi Jim,

Yes, you must have missed that in an earlier post. I had already tried the RewriteCond suggestion you made with no luck.

So...so far I have tried...

- Adding "RewriteCond %{REQUEST_URI}!^/cgi-bin/" to the .htaccess file

- Copying the entire .htaccess file to the cgi-bin

- Creating a new .htaccess file in the cgi-bin with "RewriteOptions Inherit" in it.

An interesting thing is I have this setup on about 10 different hosting providers and am having this exact same issue on all of them and none of the above options fixes the issue so it is not specific to this one host.

[edited by: Philosopher at 9:07 pm (utc) on Nov. 20, 2007]

jdMorgan

9:25 pm on Nov 20, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



If either of the following directives are missing from the .htaccess code in /cgi-bin, try adding them:

Options +FollowSymLinks
RewriteEngine on

If neither of those change anything, then it's down to your host to check to be sure that mod_rewrite code in /cgi-bin is executed before the cgi-scripts are executed. On Apache 1.x, they need to check the LoadModule list order, and be sure that mod_rewrite is loaded *after* mod_cgi. Modules are processed in the reverse order that they are loaded.

It is also possible that they've configured the cgi-bin directory with AllowOverrides None, in which case mod_rewrite (and several other modules) can't be used in that directory.

Jim

Jonathan

10:18 pm on Nov 20, 2007 (gmt 0)

10+ Year Member



Agreed that funky cgi-bin configuration is likely responsible. ScriptAlias possibly? Maybe experiment with mod_rewrite's PT flag for a possible solution?

Regardless, if you can edit httpd.conf, my suggestion is to enable the RewriteLog directive and examine the log.

Marcia

3:56 am on Nov 21, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I was looking at a long, long control panel list of supported file extensions earlier today (customized Cpanel), and .cgi wasn't on it. I looked several times, it just wasn't there in the list.

Just for the heck of it, what happens if you name that script in the cgi-bin with a .pl extension?

[edited by: Marcia at 3:56 am (utc) on Nov. 21, 2007]