Grid hosting is a somewhat recent technology that essentially emulates a single server, but whose processing power is distributed over multiple servers. There are several technologies used to accomplish this, but essentially it can be thought of as a cluster or as a self-scaling server arrangement.
The concept of it is to get the best of both worlds — you upload your website to a single server, or at least a single IP address, but depending on how much traffic your site is getting, more servers are added or removed to maintain stability. In other words, easy, 100%, infinite scalability.
It is very attractive. However, after spending the last few months using GoDaddy’s Grid Hosting BETA, I simply have to conclude that GoDaddy has it all wrong. I believe from their perspective, they consider it one of their lower end solutions, and indeed, during the beta, it is only $4.99 a month. However, infinite scalability is not something of value to someone whose websites will never scale. Scalability is a point of interest for large sites, especially large sites that could become gargantuan.
So, the truth is, the service works very well with the exception of one important factor: You can’t directly connect to any hosted file. That’s right — if you attempt to post data to a script hosted on their server, you will, at least once ever so often, be forced through a 302 File Temporarily Moved redirect. And, according to the W3C:
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
Note: RFC 1945 and RFC 2068 specify that the client is not allowed
to change the method on the redirected request. However, most
existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless
of the original request method. The status codes 303 and 307 have
been added for servers that wish to make unambiguously clear which
kind of reaction is expected of the client.
Summary: Any posted data cannot be forwarded through the redirect. Again, I’ll reiterate that this only happens on occasion, but it happens 100% of the time for a service I was trying to implement: PayPal IPN.
That’s right, every time PayPal tries to send an IPN (Instant Payment Notification) they are sent a 302 File Temporarily Moved header. Given that PayPal sends payment data via POST, and that PayPal is so fixated with security, and that the W3C expressly prohibits the forwarding of posted data through a 302 redirect, well it just doesn’t work.
And ultimately, anyone who uses any form on their website cannot reliably expect to get any results, as this redirect will prohibit the form from working.
The fact of the matter is, it really makes no sense anyway. A logical conclusion would be, well why not have PayPal submit the data to the destination of the temporary redirect? Short answer, the redirect goes to the same file.
Let’s say my IPN handler is at http://mysite.com/handler.php. PayPal sends POST data to that URL, only to receive a 302 reply to redirect to the location http://mysite.com/handler.php?3ecvxYara (3ecvxYara is just a random string of characters, and it can change). Ok so PayPal is then redirected to http://mysite.com/handler.php?3ecvxYara, where it can’t resubmit the POST data, but that’s where GoDaddy sends them. Once they hit that URL, they receive yet ANOTHER 302 which directs them back to the original URL, only this time it works. However, 2 steps ago, we were prohibited from resubmitting the POST data.
Let me summarize, GoDaddy, this SUCKS.
I have spent almost 6 months back and forth with their technical support. I would send an email, only to get the reply “Hey we got your question.” Then, a few hours later, I would get a reply “Your request has been forwarded to the high level tech guys because we low-level guys barely know how to turn a computer on.” Finally, a day or so later, I would get “We think it is a problem with your scripting. Check your script and make sure you’re not screwing up.”
At this point, all I knew was that PayPal couldn’t connect because they were getting a 302 reply. I had theorized that there was some kind error in the Grid Hosting redundancy system. Ultimately, GoDaddy admitted that it was something happening on their end. Then, finally, someone on the PayPal boards triggered me to look up the protocol for a 302, and I realized the problem. Then, I used FireBug to track the headers, and sure I enough, I found what I needed to know. So, I questioned GoDaddy as to why the 302 is necessary.
The reply:
Dear Sir/Madam,
Thank you for contacting Hosting Support.
Your issues with communicating with Paypal are related to the methods which we use
to protect our network. For security reasons, we cannot get into the technical
explanations as to why this configuration will not work.
Please contact us if you have any further issues.
Regards,
Aaron R.
Hosting Support
In other words, they can’t come up with a solution that makes the Grid Hosting system behave like a normal server, and, as I mentioned before, that is supposed to be the appeal of this technology. Give me a break … temporarily redirecting every file somehow protects their network? Wow! I guess I know now how to try to bring down their other hosting services right??
Needless to say, I will not be using Grid Hosting from GoDaddy anymore. I will next try Media Temple, as it is more matured and I have not read about any such issues. I doubt GoDaddy cares about losing my $4.99 a month, but I will deter as many people as possible from using their system at all. Their slow, inefficient, vague technical support is a frustration in itself, and the fact that they can’t get their system to work properly, well that’s just bad business.
