Horrible tech support experience


#1

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.]


#2

Can you let me know what one of the affected domains is? I’m curious now. :slight_smile:


#3

Sure Andrew. I sent the information via Private Message.


#4

Replied. Short version: it doesn’t appear that the two domains were using the same code after all.


#5

Which code? In this paragraph, the OP indicated he set them up to be identical:

[quote]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 which exhibits problems (I’ll call it the BAD one). 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.
[/quote]


#6

At the point at which I looked, the two domains were using distinct directories. I’m told in PM that the problem persisted when the domains were set to use the same directory, but I haven’t seen them in that state yet so I can’t verify.


#7

The PM was just to keep the domain itself private. The rest can remain out here.

I’ve only configured the GOOD one to serve the directory for the BAD one for specific periods of time when I was testing or having dreamhost staff test. At present, each domains serves its own respective directory.

I did spend a few hours this morning changing various files items and testing. I finally was able to get the GOOD one to fail in the same manner as the BAD one failed. However, I don’t understand how it manages to do so. Or, more accurately, I no longer understand how the GOOD one manages to successfully prompt for authentication.

The final rewrite statement in .htaccess appears to redirect everything to index.php:
RewriteRule ^(.*)$ index.php [QSA,L]

The authentication is only on backend.php and backend_dev.php.

The server behavior appears to be that the Rewrite occurs before the authentication rule, so the authentication rule should never get triggered. However, authentication occurs for backend.php on both the GOOD one and the BAD one if the index.php is missing or is plain text. If index.php is the standard one containing our code, then the GOOD one still authenticates while the BAD one fails.

I’ve been searching online for the past two hours trying to find any information which would explain this apache behavior but I’ve come up empty so far.

So, if the RewriteRule applies before Authentication, how does authenticate ever occur if index.php is plain text or missing?

Conversely, if Authentication occurs before the RewriteRule is applied, then how would the contents of any of the files be able to affect the authentication?