SoftException in Application.cpp:574: Could not execute script – HostGator

Do you have a HostGator shared account and you’re seeing Internal Server Errors intermittently on otherwise-working code?

I have a couple of domains at HostGator (not this domain). One of them experience this issue for several days. Randomly, loading any page on the site would generate “Internal Server Error” and the message in this post subject line in the error logs.

Nobody at HostGator could help me. I sat on with live chat for over an hour with a tech. During that chat session the site went down 3 times and they couldn’t tell me what was going on. I heard something about process limits, but traffic was zero (except for me, trying to load a page, and I wasn’t doing it 25 times). I asked to me moved to another node; they said they couldn’t do that. I have been so spoiled by ServInt and Linode! The problem disappeared on the first domain and hasn’t happened since.

This morning HostGator migrated another of my managed domains to a new host node. This required an IP address change, so I wonder if they changed datacenters. Right after the migration I’ve started having this error on this new domain.

If you’ve experienced this and have any information or just want to add a “me too!”, please comment. These are not errors in my code, because my code works most of the time on their server. There is nothing unusual in the access logs.

Android App Permissions

When installing Android apps, look closely at the permissions they are asking for. For example, OpenSignal wants to read my text/MMS messages, my call log, and my contacts. Why do they need that information? I’ve asked them; I don’t expect to get a reply, or at least a reasonable one. Probably something about “to improve service and the customer experience” or some similar line. No thanks.

Edit: here is their answer.

Well written, and makes sense, but I still fundamentally disagree with an app billed to “find the best signal in your area” being morphed into something that tracks data usage. In the context in which OpenSignal is marketed by its own tag line – as a signal tracking tool – it has no business doing anything with SMS/MMS and contact information. The app should be repackaged as a signal and data tracking tool to better manage user expectations, or the new app should be split out so the user can reasonably expect to grant those permissions based on what the software is expected to do. Now it is all-or-nothing, and should the app developer change their mind about what they will do with the information they can collect, there is nothing users can do. They can uninstall the app, but once the data is collected and sent back to the developer, it is no longer in the user’s control.

Payflow link invalid input errors

If you are a playflow link merchant and you recently started having “Invalid input” errors from your payment pages, check the source of your form that submits the data to payflow link. Sometime recently (May or June 2013) Payflow began rejecting HTML tags in form field input. I had a “<BR>” tag in my description field, and users were being kicked out with an “invalid input” error.

Android poor battery life, Exchange Services

I had a new Android phone the other day, fresh out of the box; set up my hosted exchange account, and my battery life was measured in hours (as in 5-6 hours). The phone was getting hot all the time and the data arrows were constantly lit. Stopping “sync” or preventing email from syncing in settings solved it, but obviously that’s not a tenable solution for a mobile device.

I logged into OWA and sent logs to myself between the phone and the Exchange server. Over the course of a few minutes there were more than 60 of these:

SyncCommand_OnExecute_Exception :
at Microsoft.Exchange.AirSync.RecipientInfoCacheSyncCollection.OpenSyncState(Boolean autoLoadFilterAndSyncKey, SyncStateStorage syncStateStorage)
at Microsoft.Exchange.AirSync.SyncCommand.SyncTheCollection(SyncCollection collection, Boolean createSubscription, Boolean tryNullSync)
at Microsoft.Exchange.AirSync.SyncCommand.OnExecute()

LogicalRequest :
<?xml version="1.0" encoding="utf-8" ?>
<Sync xmlns="AirSync:">

Command_WorkerThread_Exception :
--- Exception start ---
Exception type: Microsoft.Exchange.AirSync.AirSyncPermanentException
Exception message:
Exception level: 0
HttpStatusCode: OK
AirSyncStatusCode: Search_TooComplex
<?xml version="1.0" encoding="utf-8" ?>
<Sync xmlns="AirSync:">
Exception stack trace:    at Microsoft.Exchange.AirSync.SyncCommand.OnExecute()
at Microsoft.Exchange.AirSync.SyncCommand.ExecuteCommand()
at Microsoft.Exchange.AirSync.Command.WorkerThread()
Inner exception follows...
Exception type: Microsoft.Exchange.AirSync.AirSyncPermanentException
Exception message:
Exception level: 1
HttpStatusCode: InternalServerError
AirSyncStatusCode: ServerError
[No XmlResponse]
Exception stack trace:    at Microsoft.Exchange.AirSync.RecipientInfoCacheSyncCollection.OpenSyncState(Boolean autoLoadFilterAndSyncKey, SyncStateStorage syncStateStorage)
at Microsoft.Exchange.AirSync.SyncCommand.SyncTheCollection(SyncCollection collection, Boolean createSubscription, Boolean tryNullSync)
at Microsoft.Exchange.AirSync.SyncCommand.OnExecute()
--- Exception end ---

AccessState :

AccessStateReason :

ResponseHeader :
HTTP/1.1 200 OK

ResponseBody :
<?xml version="1.0" encoding="utf-8" ?>
<Sync xmlns="AirSync:">

These errors were coming in at the rate of 1 per second, which explains why my phone was hot to the touch.

The solution (for me) was to delete the Exchange account from the phone, delete the phone from OWA, and redo the partnership. If it makes any difference, this time I selected “All” for the length of time to download emails, and I chose manual setup instead of Autodiscover setup. Everything is working normally now.

Jawbone / myTalk Password Breach

Today I received an email from Jawbone explaining that their myTalk customer password list had been stolen by hackers. They say passwords were encrypted, but they do not say how they were encrypted. If they used pig latin to encrypt, then I should immediately go about ensuring that the password I used on the myTalk web site is not used anywhere else. But if they used bcrypt or scrypt with a high work factor and a random salt, I would be somewhat less concerned about this. Not that I wouldn’t check it, but I might do so after lunch, as opposed to, say, right now.

Of course they don’t say what encryption method was used for the passwords, which leads me to believe it leans toward the pig latin side of things, as they don’t feel confident in reassuring their customers that hackers will have to work very hard to obtain the plaintext passwords.

I was going to write to Jawbone and ask them what encryption method they used, but I bet they would first think I’m the guy that stole their data (most of their employees probably don’t even know that most modern encryption methods contain a header of sorts that says what algorithm was used, so the hackers already have this information and us customers do not!), and second they wouldn’t respond anyway, or there would be some line about proprietary information, security concerns, blah blah blah. Jawbone, you should know that once the data leaves your control – encrypted or not – it is no longer proprietary. Your customers have a right to know their relative risk and you should have given us that knowledge right away.

We are a China based imaging professionals / Rick photo editing spam!

After years of putting up with Rick and his digital photo editing services crap I think I have finally figured out a way to block these messages.

Here’s the deal. You run a mail server, and you get spam every single day from Rick offering digital photo editing services. You put “We are a china based imaging professionals” into your spam blocker/body_checks and THE MESSAGES KEEP COMING. You can’t figure out why they are still coming. Your rules are working. You forward yourself one of Rick’s messages and it is blocked. Yet they keep coming from China.

The answer is in the mail log:

Jan 19 19:23:37 dallas postfix/cleanup[21010]: 774CC582A5: info: header Subject: =?GB2312?B?RGlnaXRhbCBQaG90byBFZGl0aW5nIFNlcg==?=??=?GB2312?B?dmljZXM
gLSBQaG90byBDdXRvdXQgLSBQaA==?=??=?GB2312?B?b3RvIFJldG91Y2hpbmc=?= from[]; from=XXXX to=XXXX

I have Postfix report message subject lines in the log because it makes troubleshooting mail problems easier. Look at the Subject: header of this message. It begins with “=?GB2313?B?…” if you take that whole string and put it into Google you get no hits. But if you truncate to just the part I quoted above, you get some very interesting results. GB2312 is the character encoding for Chinese simplified. So Rick figured out that if he encodes his emails using that character encoding but such that the decoded email appears in US English ASCII characters (A-Z|a-z|0-9) then we’ll all get to read about his photo editing services in a language we understand.

Solutions vary – blocking this encoding string in the headers is what I’ll be doing (along with some other encoding strings). There are other articles on this topic once you know what to search for, with various strategies depending on your needs and your email system.

In my case I’m just adding this line to my header_checks:

/^Subject: .*?GB2312?B?.*/ REJECT # No chinese encoding please.

Happy spam-blocking!

Edit: One thing to note. I had a rule set up in Postfix that printed the email subject line in the logs (it’s my mail server, I can do what I want):

/^subject:/ INFO

This line appeared first in my header_checks file, but since only one rule can fire per email header line, after I added this to the top of my header_checks, Rick’s email started getting through again. Sure enough, testing one of his headers with:

postmap -q 'Subject: =?GB2312?B?' regexp:/etc/postfix/header_checks

resulted in:


instead of:


because only the rule that writes the subject to the log was being run. So I moved that rule to the bottom of header_checks. Now the messages with Chinese encoding are blocked (REJECT) and if any mail does get through, the subject line is written to the logs.

1099-K and transaction date or settlement date

I believe I’ve uncovered an accounting nightmare for merchants who receive 1099-Ks. I noticed that some of my monthly totals for 1099-K were off by small amounts vs. my (very) detailed monthly accounting. Turns out, the 1099-K’s appear to have been generated based on transaction date, while my reporting is traditionally based on settlement date (i.e., the date the merchant receives the money).

I would consider the settlement date to be the constructive date of receipt, because that is the date the money is transferred to my account. However, the credit card processors are handling this based on transactional data, which causes irregularities because all my bank statements show the income in the subsequent month.

Since it is not possible for a merchant to make such a logical point to the IRS and be understood, the only solution appears to be to edit the dates of the offending transactions to reflect the month (and year) reported by the 1099-K.

Way to go, people.