YAMA rewriting+redirect+htaccess



yup, Yet Another Message About. arg.
ok, so i’m frustrated with the lack of carefully worded and complete docs on rewriting & redirection in apache .htaccess. (man, if anything will be the downfall of open source it will be the lack of documentation skills of software engineers and their (our) usual inability to use English in a way that is both semantically precise and technically accurate as it applies to the topic being documented). . I believe that the problems i’m having are due to my misunderstanding the .htaccess run-time context and what the path i will be handling during a Redirect or a RewriteRule actually looks like in every case.

I wish to have an .htaccess in the root (only, where possible) of each domain or subdomain. further, i wish for every one of these .htaccess files to be identical for ease of maintenance. for externally-imposed reasons, the web document index cannot be index.html - but an index.html file will be present in some directories. Here’s what i’ve done:

  1. ix.html is the actual document index file, so I have specified:
    DirectoryIndex ix.html

  2. i need to prevent access to index.html in the case that someone has an old bookmark, or assumes index.html and types it explicitly, so i have tried 900 different things, including various Redirect-s and RewriteRule-s and none of them work in every possible case. Currently, I am down to no RewriteRules and only this redirect:
    RedirectMatch (.*)index.html$ $1
    This seems to work on all my DH domains. BUT it does NOT work on any subdomain. the docroot of the subdomain is physically inside the directory of the parent domain, altho i don’t see that this could have any bearing on the error.

so what’s wrong with that redirect, and why does it work if one types, for example, [www.]tmike.com/index.html, but not if one types dp.tmike.com/index.html?

tmike at your dot pants com
(to reply by email, drop your pants)


.htaccess files impact the directory they are in, and all directories beneath them in the filesystem structure.

One of the reasons you are having difficulty is using /home/user/domainname.tld/suddomain.domainname.tld/ as the “base” of a subdomain.

A better, and much simpler to manage, approach is to have a subdomain’s base directory “adjacent” to the location of domains in the directory tree, as in /home/user/domain.tld for a “main” domain, and /home/user/subdomain.domainname.tld for a sub-domain. This also makes it a lot easier to avoid having “battling” .htaccess directives and re-write rules.

BTW, for one who is so critical of the apache developers’ documentation efforts (careful wording, precision, and all), the borkedness of your sig is a bit ironic, don’t you think? :wink:




however, an .htaccess in a child directory is described as “overriding” one in a parent directory, and that description appears to be accurate - i.e., if a directory contains an .htaccess, the content of its parents appears to me to be completely ignored, not “merged” as i have sometimes seen it portrayed.


if the base of one [sub]domain is x and the base of another [sub]domain is y, their relationships to each other in the filesystem do not appear to matter vis-a-vis .htaccess files, given the above, assuming that both x and y contain an .htaccess. so, in what way is this an issue as it relates to .htaccess files? while your suggestion might bear upon filesystem maintenance issues, in this case the physical nesting is a help to maintenance, not a hindrance. (and i quite disagree with your assertion that peer directories are more proper for subdomains. (generally) a subdomain’s raison d’etre disappears if the parent domain disappears; this implies that a subdomain is logically within the context of a domain and its contents are rightly manifest as being subordinate to that parent context; hence, the subordinate directories).


my sig causes an error on some email address collection software that tries to parse out substring removals where instructions for doing so are explicitly provided.

tmike at your dot pants com
(to reply by email, drop your pants)


Then it appears you know a great deal more about this than do I, and will eventually get it sorted. My personal belief is that success with apache rewrite rules often involves mumbling arcane chants over the entrails of beasts, and other voodoo :slight_smile:

I’m well aware of the purpose of obfuscating your email address in the sig; my observation was meant to point out that this is usually done in such a way that a “human” can derive a vaild email address from the obfuscation, while yours is not. :wink:



ROFL it certainly seems to! actually, i was just about to run out and acquire a live chicken for just such a ritual…

tmike at your dot pants com
(to reply by email, drop your pants)


Hey, it just might help…good luck with that!

There are some pretty savvy apache rewrite guys that pop in here fairly regularly, and they might be more helpful. I do hope you get it to work the way you want it to.



Heh, yeh, all I seem to be able to work out is ‘tmike at dot com’ - ??


OOPS… well, crap… my fault, thanks for pointing out the mistake!

tmike at tmike your dot pants com
(to reply by email, drop your pants)


:slight_smile: Chris explained it better than I did …now even I can figure it out! :wink: Rock ON!



On DreamHost, subdomains are separate from the main domain in the FTP space
e.g. you will have a directory

and another

So your set-up seems a little odd.
Anyway you can use

RedirectMatch !^http://[a-z0-9_]+.tmike.com/[a-z0-9_]+(.*)index.html$ $1

This should cover subdomains and subdirectories… though I don’t guarantee it will work as it is ages since I’ve use .htaccess or regular expressions.

Let me know if you have any success and the eventual solution found.

Dreamhost Webhosting SAVE97 - To save the maximum possible amount on any plan at sign-up!