The infamous Godaddy "pageok" error

The infamous Godaddy "pageok" error

Recently, people hosted on Godaddy servers are news a "pageok" error once making an attempt to transfer files from RedCart Desktop to their Godaddy server. we've gone spherical and spherical with several of our shoppers over the previous few weeks making an attempt to resolve the problem, however sadly, the problem remains unresolved and that we were forced to quickly add Godaddy to our "hosting suppliers not supported" list.

You can see our most up to this point list of supported hosting suppliers here:

For those of you that area unit interested by the technical implications of the problem, here's a recent correspondence with one in every of our shoppers that details the issue:

WARNING: Your head would possibly hurt to a small degree once reading this.

Here's the particular error for your reference:
<!-- pageok -->
<!-- managed by puppet -->

Hi ----,

We ran a bunch of tests on your server and were still unable to resolve the difficulty. However, I do have additional data for you that i feel proves that it is a Godaddy specific issue that's out of our management.

Here's what we tend to know:

1) RedCart Desktop is our Adobe AIR application that we tend to use as a content uploader. RCD uploads pictures and .mp3 files to the server via a customary file post victimisation Adobe AIR's URLRequest category. Here's the documentation of Adobe's URLRequest class:

2) RedCart Desktop uploads pictures by posting the image information to the subsequent file on your server victimisation the Adobe AIR URLRequest class:

When it's operating as designed, the zipExtractor merely grabs the post information then moves the file to the proper folder location in your cart. If you navigate to the zipExtractor.php enter your browser directly, the Godaddy "pageok" error isn't triggered. However, if Adobe AIR makes a post to constant file from RedCart Desktop then Godaddy triggers the "pageok" error.

3) we tend to needed to visualize if we tend to the difficulty can be within the php code that resides within the zipExtractor.php file therefore we tend to set to create a take a look at.php file that contains no php code in the least then post to the current file from RedCart Desktop (Adobe AIR). Here's a link to the take a look at.php file that we tend to denote to:

When posting from Adobe AIR to the take a look at.php file we tend to received the precise same "pageok" error. This tells US that the difficulty isn't within the php code.

4) we've got mentioned the chance that the headers that ar sent within the type post from Adobe AIR would possibly somehow be triggering Godaddy to show the "pageok" error. therefore we tend to set to create a testPost.php file that creates a type post to constant take a look at.php file to visualize if we tend to may trigger the "pageok" error that manner. Here's a link to the testPost.php file:

We were unable to urge the "pageok" error to be triggered once posting a file victimisation the testPost.php script. this means that there's one thing totally different between the Adobe AIR file post and therefore the php primarily based file post that's somehow triggering the Godaddy "pageok" error. we tend to captured the raw post headers that ar being generated from Adobe AIR and compared them to the raw post headers that ar being generated from the testPost.php file. Nothing jumps out as being wrong and though it did, the headers that ar generated with Adobe AIR ar automotive vehicle generated by Adobe, which implies that we've got no management over what they give the impression of being like. Here's an immediate copy / paste of the raw headers that ar coming back from Adobe AIR that's triggering the "pageok" error:

************************************************** ***************************
POST /RedCart/rcdesktop/test.php HTTP/1.1
Connection: shut
Cookie: PHPSESSID=3mu2oodjt5sgnagrld5jrsr8t5
User-Agent: Mozilla/5.0 (Macintosh; U; Intel mackintosh OS X; en) AppleWebKit/526.9+ (KHTML, like Gecko) AdobeAIR/1.5
X-Flash-Version: ten,0,12,36
Accept-Types: text/*
Content-Type: multipart/form-data; boundary=----------ei4ei4ae0ei4gL6Ef1ae0KM7GI3KM7
Content-Length: 5824761

Content-Disposition: form-data; name="Filename"

04 right down to The watercourse to wish.mp3
Content-Disposition: form-data; name="Filedata"; filename="04 right down to The watercourse to wish.mp3"
Content-Type: application/octet-stream
************************************************** ***************************

5) once doing additional analysis on the Godaddy "pageok" error, there looks to be an amazing abundance of proof that implies that the difficulty is on Godaddy's finish. Most cases ar aforesaid to be connected to a Godaddy DNS configuration issue however most of the problems within the following threads appear to possess gone unresolved therefore it's troublesome to mention what the $64000 cause or answer is. Regardless, i believed it'd be sensible to offer you an inventory of alternative documented cases wherever others ar experiencing constant "pageok" issue. Notice however none of the subsequent cases have something to try to to with RedCart:

(there ar several several others that you simply will realize if you are doing some google searches)

Unfortunately, we're still left scratching our heads and ar still at a dead finish.

To recap, we've got essentially proved that the "pageok" error is merely generated once creating a file post from Adobe AIR to the Godaddy server, though there's no php code within the file that we tend to ar posting to. we tend to suspect that it's one thing to try to to with the post headers however Adobe does not offer US several alternative choices for posting files and uploading files to servers therefore there is solely such a lot that {we can|we will|we ar able to} do to alter the manner that files are being denote. we've got exhausted all of the probabilities (that we all know of) to post files in several ways that via Adobe AIR. This issue solely happens with Godaddy and has not been rumored with the other hosting supplier anyplace on the world. All of the higher than data leads US to believe that the difficulty is somewhere on Godaddy's finish that's quite merely out of our management. It's very not like US to go away a problem like this hanging while not a fix. we'd fully like to fix the difficulty and build all of this get away. however like I aforesaid, it looks to be merely out of our management.

I hate to recommend such associate extreme action, however if you actually need to urge this resolved ASAP then i'd powerfully recommend linguistic communication up with associate account web site five. they need been doing free migrations for our shoppers and everybody looks to be terribly happy once moving everything over. i do know that it seems like a giant headache, however they'll simply pay attention of the whole method for you creating it as pain free as attainable. And yes, you get to stay your same name therefore that is not a problem. They essentially move your files, databases...etc then once everything is traced over they're going to build a DNS amendment to flip the switch and route all of your traffic from Godaddy to their server with none period for your shoppers. It's a lot of easier than it sounds.

Please let Pine Tree State understand if you've got any queries. sorry the long email.