Was I too mean? (long, rambly, and techy)

I recently transitioned my blog from a LAMP stack at 1and1.com (who I was happy with) to a Windows/IIS7 stack at GoDaddy.com (which was cheaper, and more importantly, Windows-based). At both locations I had multiple domains registered with the same account.

I wasn’t thrilled with 1and1’s side of the transition (they just didn’t respond to the requests, and waited to the automatic approval after five days to go through), but GoDaddy’s system was fairly good. Their control system is a little too separate (Domains are managed in one UI, Email has to be accessed through a completely different UI, and Hosting is managed in a third), but after initial setup, I shouldn’t be changing the former two sets of data very often.

However, I started getting into trouble when I tried to setup WordPress for both Mandrina and my blog (ed: blogs? Abigail!). The GoDaddy “Hosting Connection” application will allow you to install a set of applications automatically — setup a database and everything. Unfortunately, it will only install for the primary domain for the account — which I set to be something nonexistent. So I needed to customize to go through and reset all paths and domain references by hand, because my blog is not, in fact located at “http://www.some-random-name-23123-that-no-one-likes-123123.com/office-monkey”. I had a bit of problems originally, but I eventually got it straightened out — the biggest trick was in just importing my old MySQL databases, and making only the necessary modifications (directory on disk). That part was easy, and all posts and comments came along for free!

I still have to work out enabling Plugins, but that is likewise minor. There was nothing (aside from Akismet Anti-Spam) that I HAD to have).

The one thing I really wanted to get working, though, was Permalinks. The pretty post names you see as the link behind the title for a particular post.

instead of
http://www.office-monkey.com/?p=23
(Different posts, I was lazy.)

IIS doesn’t have RewriteRules built in as Apache does, so where WordPress defaults to writing a .htaccess file on the LAMP stack, it just doesn’t work on PHP/FastCGI on IIS7. However, I came across a mechanism whereby it could work, making use of a custom 404 error handler.

This is where it got tricky for a minute — the sample I was able to find worked for a single domain. However, I needed a single shared 404-processing.php file to handle requests for multiple subdomains. However, I got creative, and figured it out — which made

possible instead of the uglier

Interesting thing, happened, though. I went through, and got all the post links working, category links, everything. No problem whatsoever. However, the homepage (http://www.office-monkey.com aka http://www.office-monkey.com/index.php) would not work. It would display a themed page, with no meaningful content. After an embarassing amount of time spelunking in the WordPress PHP source code, I discovered that the “Page.php” file was being processed, rather than the more appropriately named “index.php” file.

It worked when the permalink format was:
/index.php/%yy%/%mm%/%dd%/title
but not when:
/%yy%/%mm%/%dd%/title

My initial guess was that my 404-redirect hack was causing problems, but I was able to quickly establish that it wasn’t being called at all. The one interesting thing I found was that regardless of the permalink format, both scripts were trying to load “/office-monkey/index.php”, where /office-monkey is the subdirectory holding this site’s main content.

I poked around for a long time, then came across a Microsoft KB article — http://support.microsoft.com/kb/954946, alluding to an undescribed problem in how IIS7’s FastCGI implementation could possibly misset $_SERVER[‘REQUEST_URI’], leading to problems with, gasp, WordPress! I emailed GoDaddy for assistance, asking if the hotfix for the issue had been installed. They asked a few boilerplate questions, then escalated it.

I came up with a minimal repro:
< ?php echo $_SERVER['REQUEST_URI']; ?>

I had a friend (hi, Jonathan!) run it on a similar configuration on a LAMP stack.
His results?
/request.php
My result?
/office-monkey/request.php

It turned out that the first type of permalinks (including /index.php/ worked only because WordPress handled them differently. They shouldn’t have. The pretty permalinks, on the other hand, tried to match “/office-monkey/index.php” where they were coded to match “/index.php” — since that first default match didn’t apply, a later match for a random page (which didn’t exist) was triggered, and page “/office-monkey/index.php” was loaded.

IIt all came down to $_SERVER[‘REQUEST_URI’]. I added that information to my support request. I tracked down an individual on the IIS team who blogged about the KB article, and he helped me verify that the issue I was seeing with REQUEST_URI was the one fixed by the FastCGI fix (http://ruslany.net/2008/08/update-for-iis-70-fastcgi-module/). My short term fix was to dump the matching Permalink rule (I don’t use WordPress pages anyway).

Meanwhile, I got a response from GoDaddy, which I’ll summarize:
1) We can’t tell you what patches we have installed or when we install them, but we install patches on a regular schedule, and criticl patches as needed.
2) You’ll have to rewrite every script you’re using to edit $_SERVER[‘REQUEST_URI’] to exclude that leading directory.

I was a bit flabbergasted as to their resolution, and the lack of actual information it provided. So I emailed them back:

Thank you for the update. Unfortunately, some additional information renders your comments less useful than they could otherwise.

I independently verified the intended purpose of the Microsoft Hotfix corresponding to MS KB 954946. You can see the thread here: http://ruslany.net/2008/08/update-for-iis-70-fastcgi-module . As you can see, a Microsoft employee working on IIS verified the cause of the issue I see regarding REQUEST_URI when accessed via FastCGI+PHP, as well as that the hotfix for the KB article would fix the issue.

As far as I have been able to establish the hotfix in question has not been published as an update, but has been out for almost three months. While I can understand your reluctance to publish the current patch level on any servers, as it would serve as an invitation to hackers of all stripes and skill levels, I cannot ascertain whether GoDaddy’s server plans include ever installing this hot fix.

This issue will affect anyone who is running PHP scripts on IIS when dealing with either multiple domains or subdomains. It is a known issue with PHP/FastCGI on IIS7, and would be time-consuming, painful, and incompatible to fix at the source level. I will need to customize my fix for each of several domains, and will need to spend substantial time I don’t have in review in order to assure I cover every entrypoint. I’m certain that I will not be the only person who will or has been affected by this, and given the existence of a fix for the issue, I am surprised and disappointed that I can’t get any confirmation on attention to repair what is in effect a defective server component.

I would like to ensure that I understand the position you are putting forward:
– GoDaddy will not publish their patching policies beyond asserting that updates are applied regularly and critical patches are applied as needed.
– GoDaddy will neither confirm nor deny their intention of ever installing a server hotfix that decreases the value of their shared hosting on IIS7.
– GoDaddy would prefer that individuals personally customize applications that are installable from the HostingConnection/Metropolis site at the source level rather than installing a fix from a major software company.

I had heard good things from several people regarding hosting at GoDaddy, so I’m hoping I’m misunderstanding the intended solution. If this hot fix will be included the next time a set of patches are applied, I can certainly come up with a workaround for the time being. If in order to maintain system security of a hosted application I need to customize it at every patch, I find myself not finding myself in complete agreement with the praise I have heard.

I hope I’m wrong.

Now, my question to anyone actually read this far — was I too mean to the poor support technician?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  1. Jonathan says:

    Mean? Not in the slightest. I am flabbergasted that they actually suggested you work around the issue by hand-editing all of your sources instead of offering to apply the hotfix (or, at the *very* least, promising a future application of said hotfix).

    Let us know how they respond to your missive.

  2. Sora says:

    I’m not surprised in the least at how they responded, frankly. Front-line support is, with relatively few exceptions for individual people, simply not capable of understanding the base issue here. All they know is what they told you — if you’re lucky, they might file a case with their DEV team.

    I think your email was perfect — it makes it pretty damn clear that you know what you’re talking about, and don’t want to settle for their bullshit answer. It gives them the choice of either giving you the BS again (knowing it’ll piss you off and possibly lose your business), or trying to escalate the issue up their chain. Which, tbh, is the best result you can realistically hope for.

  3. Andrew says:

    I had already been escalated — and was everytime I replied, which seems silly; I had the same incident ID, but on every reply it needed to be re-escalated.

    I finally spoke to a guy named “Wayne” on the phone. He was more explicit on why they couldn’t commit to any patch schedule, but it still boils down to the same set of information. They need to verify the patch themselves before deploying; they need to batch the patches together to minimize down time; they need to evaluate the impact and appropriateness of the patch; and then they need to stagger installations across multiple groups of servers.

    All true, but the conclusion was that they couldn’t even confirm that the patch would eventually be considered for application, and if I want to remain with GoDaddy, I will have to alter every plugin and application written in PHP to remove the /office-monkey prefix, but only when it’s present — and different for each subdomain I’m applying the application to.

  4. You are one of the few people that i have come accross that is happy with 1and1. I don’t have any beef with 1and1’s web hosting. However, I curse the day I ever listed any domains with them. Check out Red Flag for some customer comments.
    It should be a warning that when their phone is answered by a recording that tells you if you have gotten a notice from NCO, a collection agency, to press a certain number. If they are a reputable business, why do they have to send so many accounts to a collection agency?
    The Eastern Pennsylvania /Washington DC Better Business Bureau have given 1and1 an “unsatisfactory” rating. It is my understanding that 1and1 gets a complaint almost every day. An investigative journalist, Kelli Jack has written a series of articles about them and has a pending law suit. She says: “1and1 Should Be Shut Down.”