What doesn’t make sense to me is that the FileExists check went through (I don’t get why you use !-f instead of -f. Isn’t !-f saying “File does not exist”?): RewriteCond %{REQUEST_FILENAME} !-f
BUT the rewrite rule following:
RewriteRule .? /%2/index.cfm?\$isFile=%{REQUEST_FILENAME} [L,NC]
DID take me to: /www/index.cfm?isFile=%/ui/css/am.reset.css
Here’s what’s killing me. I don’t comprehend why by the time I’m at the red, %2 is nothing. I know it’s because I don’t understand back references or the difference between %n and $n variables. But because this keeps becoming nothing, I can’t do a proper file check nor can I do a proper re-write.
That doesn’t look correct as ui is not c:\ui, is it?
I used NOT file to forbid the redirection if the file exists.
I’m afraid that the RewriteCond statements for the non-subdomain version have gone missing with the result that the subdomain redirection will be overwritten. Care to show the current .htaccess for me once again?
# IIS Mod-Rewrite configuration file
RewriteEngine On
RewriteRule /\\.htaccess$ - [F]
#Ensure localhost is calling valid subdomain and project
RewriteCond %{HTTP_HOST} ^((acp|clients|files|images|ssl|www)\\.)([-a-z0-9]+)\\.(localhost) [NC]
[COLOR=SeaGreen]Look at the HTTP_HOST and make sure it's one of the aforementioned subdomains, then . then a domain name, then . then "localhost"[/COLOR]
RewriteCond /%2%{REQUEST_FILENAME} -f
[COLOR=SeaGreen]If "/www/ui/css/am.reset.css" is a file... (because %2 should = "www" and REQUEST_FILENAME should be "/ui/css/am.reset.css"[/COLOR]
RewriteRule .? /%2/index.cfm?\\$isFile=%{REQUEST_FILENAME} [L,NC]
[COLOR=SeaGreen]I have no idea what ".?" is, but rewrite it to /www/index.cfm?$isFile=/ui/css/am.reset.css (This step is done if the previous Condition is true)[/COLOR]
RewriteRule .? /%2/index.cfm?\\$notFile={REQUEST_FILENAME} [L,NC]
[COLOR=SeaGreen]Again, no idea what ".?" does, but if the condition was NOT true, rewrite to /www/index.cfm?$notFile=/ui/css/am.reset.css[/COLOR]
I’ve taken the “production” code out (and stored it safely) cause I’m just testing on development right now. I’ve written in GREEN what I think is happening (probably wrong)
As for “no subdomain specified”, I too took that code out (and am safekeeping it) and am testing all my calls right now WITH a subdomain specified, ie:
Sorry, missed this one. Didn’t expect to see an IIS question in the apache forum. Not sure how to approach this. What exactly what “IIS mod rewrite” are you using?
[This assumes it is IIS7/UrlRewrite Module 2.0 which is the most likely scenario]
First, If the code is in your web.config, please post it so we can understand what you are trying to do. Second, I have had some cases where auto rewritten rules, especially complex ones, did not translate perfectly for some reason or another.
I would try to ditch the subdomains unless there is a good reason for them I can’t see. Much easier to work with http://localhost/someproject and not have the core rewrite script care about subdomains. I would also use a different configuration on production. There are going to be different variables – even if they are as much as marketing gave out a corrupted URL you need to rewrite to support.
Each www is 5 levels down from the C:\ (?) drive’s physical root. If you can’t (won’t) use {REQUEST_FILENAME} then use %{DOCUMENT_ROOT} and the file/directory you’re testing.
Hi Wyatt! Welcome back! To bring you up to speed (sorta, kinda, almost), aaron is using a Redirection Module which claims to be (nearly) identical to mod_rewrite (exceptions as noted about six posts up from here).
I have to agree that it’s the subdomains which have been causing the problems but they’re easily handled with mod_rewrite. How does IIS handle VirtualHosts?
@wwb_99
It’s by a company called Micronovae. Here is a link to their “Apache Compatibility” support for the product. The only things it doesn’t support are because IIS doesn’t support them. I am using them because my host moved to them, and I really want pretty SEF URLs.
If by “Physical Root Directory” you mean that site’s root location, then for this project, it is “c:\inetpub\wwwroot\projects\aaronmartonecom” (as you have noted with the directory structure, “projectA” would be “aaronmartonecom” folder)
As far as I know, I can use {REQUEST_FILENAME} or {DOCUMENT_ROOT}. I changed the mod rewrite code to dump {DOCUMENT_ROOT} and I get:
This isn’t correct for 2 reasons. Assuming the first RewriteRule is what happens when a file IS found (because I made the URL variable called isFile), there is NO FILE located at /www/this/that. So it seems that our file exists check isn’t working properly.
/www/this/that should be determined as NOT being a file and should then be rewritten as /www/index.cfm?$notFile=/this/that
DOCUMENT_ROOT seems to be dumping the same thing REQUEST_FILENAME does. “/this/that” in the previous example.
When I say it is at /www/index.cfm, that is relative to the site’s root (c:\inetpub\wwwroot\aaronmartonecom) but not the server’s root (c:\inetpub\wwwroot).
Yeah, after doing about 30 more tests, I’ve come to confirm that the file exists check is failing miserably as to how I understand it. I’ve given it paths to multiple locations, and the moment I think it’s acting as expected, I then change the filename of what was requested from am.reset.css to am.reset2.css (which doesn’t exist) and the rewrite runs as if the file existed.
OK, with further testing, we have a new culprit in addition to the -f flag.
It seems our variables are becoming nothing magically. My “If file doesn’t exist” redirect, well, I checked the log files and boom, %2 (which should be the subdomain, ‘www’ in this instance), was sure enough nothing.
I forced the “no file exists” rewrite to “/www/ui/css/crap.css” (I made a crap.css file) and sure enough, the file was rendered in the browser (like how I want). But because %2 for some amazing reason didn’t exist, it was going to “//ui/css/crap.css” which didn’t work.
Disappearing variables and faulty file exist checks. These are our problem children. Now to unravel the mysteries of why they disappear and don’t check files…
Servers require the absolute (local) path to a file/directory in order to determine whether the file/directory exists, therefore, you either need to use the {REQUEST_FILENAME} which automatically includes the {DOCUMENT_ROOT} (in Apache) or use {DOCUMENT_ROOT} when defining another location.
Since your second RewriteRule contains NO RewriteConds, it’s an absolute redirection because .? will match anything. It’s no wonder that any URI is redirected to /%2/index.cfm?\$notFile=%{DOCUMENT_ROOT} where %2 does NOT exist. Add RewriteCond(s) which will avoid the ambiguity.
Because of this RewriteRule (comment it out to see what I’m saying is correct), nothing else will matter in your code/testing.
Thanks. I’ll give it a shot but I gotta do so later.
I had this week’s wed/thur/fri off giving me a 5-day weekend and I’ve spent well over 25 hours of my time on these rules. I’m a little too frustrated at it at the moment to think clearly and have found that if I distance myself from the problem and take it on later with a more clear mind, that I usually get better results.
Right now I’m too frustrated I wasted so much time on it and go nowhere developing my personal website. I got one more free day tomorrow, I’ll try to take this on bright and early tomorrow. For now, it can claim victory for winning another fight, but it won’t claim victory for the war! I will prevail!..just…not now. 8:)
Getting up from the computer and taking a shower (before bed) has ALWAYS cleared my mind and, more often than not, resulted in a solution. Anyway, it’s better to step back and clear the mind and get a good rest. Catch you later.
Hmm. You know what, I’ll give that a shot. Maybe I can forego the night-long wait and just let the shower refresh my mind.
When I get out, I’ll take on the file exists problem first, then the back-reference issue next. Well, no time like the present to try it out. Then again, who the heck wants to get out of a nice hot shower?
All have not run the next RewriteRule and instead run the “other” RewriteRule. We have our first issue! File exist checking isn’t working. Even though documentation says the RewriteCond directive is:
RewriteCond [test-string] [pattern] [flags]
If this is true, I’m missing an argument, since I only have the test-string and the flag. This may be why my file exist checks are not running properly. I would have thought this program would fault if my syntax was bad, but it doesn’t seem to.
You’ve either not read or completely missed the point of my last several posts: Your PHYSICAL PATH to index.cfm is C:\inetpub\wwwroot\projects\projectA\files\www\index.cfm yet you’ve tested everything BUT that!
If that redirects to 404.php, you’ll see it in the location box. If not, replace projectA with aaronmartonecom and try it with the real name of your project’s directory.
Okay, after a good night’s sleep, you’ll understand.
Yeah. Comprehension is definitely my problem. When my co-worker tries to explain something to me he does 2 things we’ve found that completely derail my (limited) train of thought.
He’ll go off on a tangent and use another analogy that doesn’t connect for me or he’ll use terminology which is either incorrect, or we have 2 different interpretations of what it means, throwing off my comprehension of it.
When you said “path”, originally I think of pathing using “c:\inetpub\wwwroot\…” syntax. But so many samples online said paths were “/wwwroot/project/…” I understand the concept of absolute vs. relative pathing, but in 100% of the examples I found, the test examples of -f (and !-f) showed “/based/pathing/etc”. I assume “Physical directory” is the actual path to the project, “c:\inetpub\wwwroot\projects\aaronmartonecom”
All failed…er passed… er… It called the /index.cfm?bad page, let’s just say that.
I think I’ll try a new tactic. Gonna go get a haircut and see if the “weight off my shoulders” helps me in the end.
The only thing I thought about after all this work was "did I escape special characters in those paths like : and \ properly?) Still, the regex tester built into this tool said everything looked good, so I assumed that was fine.
