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.
Pretty soon it will be a 2010 model. Anyway, recently I was hauling a load of stone, and the driver’s side rear spring hanger’s rivets broke lose and bent the hanger away from the frame. On closer inspection, the rear hangers on both side are quite rusted, and they should have been replaced years ago.
That is good stuff!
WordPress 3.0, multi-sites, and migrating only some of your posts
I started my original blog a little over a year ago now simply as a way to have a place to post thoughts online. As it progressed and I started to flesh out my music site, I realized that I actually have at least 3 distinct types of thoughts I want to post: music-related, general commentary on my life, hobbies, and interests, and philosophical topics.
WordPress is extremely powerful, and I quickly began using its RSS functionality to feed my music related posts to my music website, but, as it turns out, this is kind of bad from a search engine perspective. I ended up using cross-domain canonical URLs to make Google happy. Additionally, it was kind of confusing. While I don’t really have much traffic to any of my sites, I like to pretend that I do, and it just wasn’t adding up.
Then comes WordPress 3.0 which allows you to host multiple blogs (even, unofficially, on multiple domains), so it gave me the opportunity to allocate content correctly to my domains.
There are drawbacks, of course. It’s not like you get to just make posts and decide which domain you want it on. You still have separate sites with separate management profiles, etc., it’s just that anytime you upgrade core components (such as themes, plugins, and even WordPress itself) you don’t have to do it for every blog.
Plus, all your content is in a centralized, easily accessible place. Perhaps in the future more fine-tuned enhancements will evolve, but for the time being all I had to do was some MySQL footwork (in moving the right posts to the right blogs, which was simple enough as I already had “Music” and “Philosphy” categories).
I have had crimulus.com reserved for some time as my “personal” site — projects I’m working on, hobby showcases, etc., but I never really fleshed it out. My music site, jeremytharp.com, is about 5 years old now, but it relayed podcast data, music news, etc. for anyone visiting that site, but, for a search engine, it treated it as if it were hosted on my actual blog which is at coffeecuphalfmoons.com.
To summarize, I just wanted to express how pleased I am with the feature as well as inform any readers (if you exist) of the changes.
Finally, for the technological grit, if anyone else intends to do this, I had to make a modification to my coffeecuphalfmoons.com theme.
I had plenty of indexed content, so now most of those are on crimulus.com or blog.jeremytharp.com, so links from search engines would generate a 404. I simply modified my theme’s index.php send a GET request for the $_SERVER['REQUEST_URI'] on each of the domains (crimulus.com and blog.jeremytharp.com) in the event that have_posts() returned false. If either of those requests returns a header code other than 404, I send a 301 redirect for that.
So, a search engine refers a user to http://www.coffeecuphalfmoons.com/a/post/that/i/moved/
I check (using cURL) to see if http://www.crimulus.com/a/post/that/i/moved/ or http://blog.jeremytharp.com/a/post/that/i/moved/ returns a 200, 301, etc. If so, then it’s probably the post that was originally referred to.
This is how you help keep pagerank value and link-juice when you’re migrating only a few posts from a blog on one domain to a blog on another. At least, that’s how I did it.
Posted in Commentary, Computers, Reviews