views:

41

answers:

1

Hey all,

I've recently made some minor changes to my website's folder structure, and now one of my rewriterules seems broken.

in the past I had a /mydomain.com/ folder in public_html in which a wiki was set up. In the same folder were some folders that I used for subdomain access, like members and files.

The old setup:

#www to main website
RewriteCond %{HTTP_HOST} ^www.mydomain.com$
RewriteRule ^(.*)$ mydomain.com/$1 [L]

#subdomain to folder (members. => /members/, files. => /files/, etc)
RewriteCond %{HTTP_HOST} ^(.*).mydomain.com$
RewriteCond %{HTTP_HOST} !^www.mydomain.com$
RewriteRule ^(.*)$ mydomain.com/%1/$1 [L]

Fairly easy, and when I typed in files.mydomain.com/myfile.zip it worked without any problems.

Recently I installed several languages of my wiki (which is in fact irrelevant to the question, but just to elaborate the situation) and I made the following rule:

#to the right language folder (www = en)
RewriteCond %{HTTP_HOST} ^(www|nl|es).mydomain.com$
RewriteRule ^(.*)$ mydomain.com/%1/$1 [L]

#subdomain to folder (members. => /members/, files. => /files/, etc)
RewriteCond %{HTTP_HOST} ^(.*).mydomain.com$
RewriteCond %{HTTP_HOST} !^www.mydomain.com$
RewriteRule ^(.*)$ mydomain.com/misc/%1/$1 [L]

Obviously, the different language wikis are set up in mydomain.com/www/, mydomain.com/es/, etc. This works perfectly fine. The problem lies in the second part, the subfolders. In the same mydomain.com/ folder I created a misc/ folder to store all the misc stuff (including the subdomain folders). I figured just adding the /misc/ in the path (like I added the language folder name in the first rule) would make it work.. but it gives me a 500 error. Neither the old setup nor the new setup have any .htaccess lines in any folders that could conflict with the second rule.

Can anyone spot the error, or tell me how to systematically check this setup for bugs?

+1  A: 

The easiest way to prevent the redirection loop I believe is happening is to just check if you've already rewritten the URL to where you intended it to go. We can do this a few different ways; if you know that the file will exist once you've rewritten it, you can condition on %{REQUEST_FILENAME} !-f, for instance.

In your case, since you're rewriting everything to a common folder within your /public_html directory, we can just check if that's already been done:

#to the right language folder (www = en)
RewriteCond %{HTTP_HOST} ^(www|nl|es)\.example\.com$
RewriteCond %{REQUEST_URI} !^/example\.com
RewriteRule ^(.*)$ example.com/%1/$1 [L]

#subdomain to folder (members. => /members/, files. => /files/, etc)
RewriteCond %{HTTP_HOST} ^(.*)\.example\.com$
RewriteCond %{HTTP_HOST} !^www\.example\.com$
RewriteCond %{REQUEST_URI} !^/example\.com
RewriteRule ^(.*)$ example.com/misc/%1/$1 [L]

Admittedly, I'm not sure why you're experiencing issues now, but weren't before. I ran your original rule set on my test server and ended up with an internal server error due to too many internal redirections, so there must be differences in our setup. In any case though, hopefully this will get things working for you.

Tim Stone
I'll try this in a sec, but the /example.com/ subfolder shouldn't be in the uri at any time.. there's no [R] flag in the rewriterule so it should remain hidden. I could try checking for the existence of the file, but if I entered an incorrect filename that'd mean I still get a server error instead of a regular 404.Also, it should mean the first rule wouldn't work either, yet it does. The error lies in a difference between both rules but I can't figure out what is different. I've checked the htaccess files for the first rule but I can't find anything either.
Litso
@Litso - I forgot to explain this, but the value of `%{REQUEST_URI}` is changed internally after you perform the initial rewrite to include the new internal request path, even though this transformation isn't visible to the user, which is why we can perform that check.
Tim Stone
Thanks, I didn't know that last part. Checking for /example.com/ in the uri did seem to work after all, I should just have listened :PAt least I've learned something today.
Litso
@Litso - Ah ha! I think I figured out why things broke between setups too, although it's a lot of guessing on my part. Before, when you had a single wiki, was there a separate `.htaccess` file for the wiki in `/example.com`? If so, and assuming when you installed new languages that `.htaccess` file was moved to the respective language directories, in your original setup, a request for your files was on the same request path as the wiki's `.htaccess` file, and the rules from your `/public_html` directory were ignored (the rule set doesn't combine with the one in the parent directory)...
Tim Stone
...Once you added the languages though, this was no longer the case, so the requests for files were still controlled by the `/public_html` `.htaccess` file, and you were subject to the redirect loop issue. Since your wikis still have their own `.htaccess` in their language-specific folders, those rules still overwrite the rules in `/public_html`, allowing the first rule to still work as it did before the update.
Tim Stone
I thought this was not the case, but you make a good point. Perhaps this is indeed what happened.. at least everything works now! Thanks a bunch :)
Litso