I just need to share with all of you my current experience with Dreamhost tech support. They are a Nightmare.
I reported last Thursday that two of our subdomains using identical .htaccess files were behaving differently from each other.
Travis T tried to help me for a while. Then Brian S chimed in most unhelpfully that they don’t troubleshoot .htaccess files and tried to shunt me over here to the discussion forum. I told him that the problem isn’t in the .htaccess file, as it works perfectly in one subdomain but not in the other; it’s a server problem. I never heard back from him.
By Sunday, still not having heard back, I submitted another ticket noting that three days without a response was unacceptable and requested that the previous ticket be addressed and resolved. Andrea responded this time saying that she would be happy to help. I further explained the problem to Andrea and then to Patrick M. I have to give a little bit of credit to Patrick M for identifying and implementing a workaround. But then he loses most of that credit because he couldn’t identify a root cause.
I get the impression that Andrea’s responsibility is to placate aggravated customers, as each time I expressed my frustration she suddenly was back on the case.
For Patrick M, I managed to simplify the problem dramatically in order to illustrate that there is indeed a server problem. I reconfigured the subdomain (I’ll call it the GOOD one) which was properly handling the .htaccess file so that it served the directory structure of the subdomain (I’ll call it the BAD one) which exhibits problems. Lo and behold, the GOOD one STILL handled the .htaccess file properly and the BAD one was STILL a problem. Further, I replaced the file that I was trying to access with a plain text file. So the GOOD one executed the rules in the .htaccess file and served the plain text file. The BAD one continued to misinterpret the rules in the .htaccess file resulting in it serving index.php (with invalid parameters created by the misinterpretation of .htaccess) instead of the requested file. [Edit: or perhaps the GOOD one is actually behaving oddly by authenticating before it redirects?]
Patrick M ultimately told me that the problem was due to differences in our application. I replied to him pointing out (once again) that there are no differences because the two subdomains were serving the same directory at the time. I asked him to escalate the problem if he was still unable help.
Shocker, here’s Andrea again. This time she escalates and files a bug report. I just received a worthless response from her:
“I have heard back from the developer who looked into your case. She checked on your htaccess file, and noted that it’s not something our system created for you, but your application. As such, the difference is based on whatever your application is doing, not our system. However, she suggested that if you can provide a test case error where the htaccess works differently on two subdomains that are running out of the same folder, but are not using your app, we’d be happy to look into it for you.”
This is essentially what I setup on Sunday for Patrick M, and subsequently unraveled on Monday, though of course it was still serving our app. The very suggestion that I could miraculously recreate an apparent bug by creating two new subdomains is just mind boggling. What was most lacking for this and every other response is any suggestion of how the BAD one manages to get to our application files at all prior to authentication when the GOOD one prompts for authentication immediately. [Edit: and before any request gets logged by the application]
[Edited for tone.]