Announcement

**Nadeem** · 03-Mar-2004, 03:55 PM

Hi Richard

Just to check this problem, if you go to "Help | About Internet Explorer", are you using version IE v6.0.28?

If so, then please go to the following Microsoft Knowledge Base article

Its a know MS Bug with IE v6.0.28, make sure you download the 32 bit version on that site

Kind Regards

**pinbrook_nick** · 06-Mar-2004, 01:22 PM

I know this is an M$ bug, but would it be possible for you to release an amended version of the orderscript that would circumvent the problem? Otherwise unsuspecting customers could be lost.

Here is my solution in the interim anyway (it places a warning on the checkout page, with a link to the MS fix):

Edit Act_Order01.html

Find the lines that read:

Code:

<hr size=1 align=CENTER width=CUSTOMVAR:ACTSTDWIDTH>
NETQUOTEDEL:SHIPANDHANDLEPHASE

And replace with:

Code:

<hr size=1 align=CENTER width=CUSTOMVAR:ACTSTDWIDTH>
<br><a href="http://support.microsoft.com/default.aspx?kbid=831167" target=_blank><font size=4><b>IF YOU GET AN INPUT IS 
NULL ERROR AFTER CLICKING NEXT, THEN YOUR INTERNET EXPLORER HAS A BUG.<br>TO FIX THIS BUG, CLICK TO GET THE (32-bit) PATCH 
FROM MICROSOFT.</b></font></a>
NETQUOTEDEL:SHIPANDHANDLEPHASE

**Mike Hughes** · 18-Mar-2004, 08:05 PM

I agree with Nick on this.

I don't think it's acceptable for Actinic to say "update your browser because it's a microsoft problem". This is something that is costing us money as there are lots of people out there using IE 6.0.2800 (including me) because it's the latest service update.

If it can be sorted in Actinic then I'd like to see new release to fix it. This is costing us money, customers and reputation.

Mike

**pinbrook_nick** · 18-Mar-2004, 08:28 PM

Perhaps Actinic could take this up with Microsoft (if they have enough leeway) and try and persuade Microsoft to categorise the SSL fix as a critical update. And maybe similarly for AOL? Although the best fix would be one in the Actinic code. With SSL being advised over actinic inbuilt encryption, it is important that it works error free.

**Mike Hughes** · 19-Mar-2004, 09:24 AM

It's hard to quantify how big a problem this is, but let me give everyone some supporting information to show why I don't like it.

I use secpay for credit cards and direct debit, but also allow the option of 'send cheque with order' (a variation on the 'invoice with order' method).

Historically, only about 2.5% of my customers use the 'send cheque with order' method and 50% of them actually send a cheque (or pay by another method when I send them an email).

From around mid-february though, this has changed dramatically.
I'm now getting about 10% of orders as 'pay by cheque' ( 4 times as many) and very few are actually completing (certainly less than a fifth of normal). I've also had a strange drop in overall sales & conversion rates to about half their normal level.

I think this may well be down to people having problems getting to the CC processing screen due to the IE bug. They probably back up and try again, and then some of them are actually trying another payment method (in this case the 'send cheque with order' method). Due to their problems I'm not surprised they're walking away from the sale.

If I'm right then this problem could be costing me between 10% (the number of customers actually bothering to go back and try the 'send cheque' method) and 50% ( the drop in sales and conversion rates I've seen) of sales over the last month.

It's hard to be certain what is causing this, but there's a known problem that could explain it and I'd like to see it fixed in Actinic if possible.

You should too. If it's happening to me, it's probably happening to you too.

Mike

**Nadeem** · 19-Mar-2004, 10:24 AM

Hi there

Thankyou for your comments and views, we are considering the points made in this discussion. I will post with a detailed response later on what we can do.

Kind Regards

**Nadeem** · 19-Mar-2004, 04:31 PM

Hi there

Just recieved a short term fix from the developers, It is a script change which has a helpful message, rather than the it displaying the input is null.

Edit Actinic.pm.

Search for 'Input is Null', you will see...

return ($::FAILURE, "The input is NULL", '', '', 0, 0);

replace this line with...
return ($::FAILURE, .
"The input is NULL No data has been received." .
" This may be due to a known bug in a Microsoft run time file." .
" The bug along with the solution is described <a href='http://support.microsoft.com/default.aspx?kbid=831167'
target=_blank>" ."here</a>.", '', '', 0, 0);

We are still investigating this issue, and hope to have a better fix next week

Kind Regards

**Mike Hughes** · 19-Mar-2004, 04:58 PM

Thanks Nadeem,

Is there any way of generating an alert email when this happens (it could use sendmail if any easier than the actinic version) ? this would help to quantify how serious the problem is.

Mike

**Darren B** · 19-Mar-2004, 05:10 PM

is this problem only with v6.1.4 or all v6

Cheers
Darren

**cdicken** · 19-Mar-2004, 05:14 PM

The problem is with every single site on the Internet that uses form inputs to communicate with files in SSL URLs - i.e. it is not just Actinic.

**Mike Hughes** · 19-Mar-2004, 07:45 PM

OK. I've made the change and don't seem to have broken anything.

One thing I did notice though. It looks to me as an extra . has appeared in the code after "return ($::FAILURE," which I've highlighted in red below.

*********************************

Edit Actinic.pm.

Search for 'Input is Null', you will see...

return ($::FAILURE, "The input is NULL", '', '', 0, 0);

replace this line with...
return ($::FAILURE, .
"The input is NULL No data has been received." .
" This may be due to a known bug in a Microsoft run time file." .
" The bug along with the solution is described <a href='http://support.microsoft.com/default.aspx?kbid=831167'
target=_blank>" ."here</a>.", '', '', 0, 0);

***************************************

I've removed the extra dot for consistency with the old code. Let me know if this is right.

Mike

**rmladden** · 21-Mar-2004, 02:13 AM

This error does not seem to make it into the error log.

Add this line after the return line to get an e-mail:
SendRichMail('smtp.yourisp.com', 'receive@yourdomain.com', 'The input is NULL', ' ', "", 'send@yoursite.com');

You have to hard code the smtp server, the e-mail address you want to get the notification, and the e-mail that sent it (just so you can tell where it came from).

I cannot force the error so it is not tested, but it did not break anything. I'm curious to see how pervasive this is.

**Mike Hughes** · 21-Mar-2004, 10:28 AM

Thanks Bob,

Rather than wait for details on sending an email, I added a non-existent image into the error message so something will show up in my error logs.

Yesterday was an extremely slow day, but so far the ratio of orders to errors is about 2:1. Don't count this as typical as it's only based on a small sample, and I think that in at least one case the customer retried successfully.

What I can say though is that even on a quiet day it is happening often enough to be causing problems and definitely needs to be sorted.

Mike

**rmladden** · 21-Mar-2004, 02:25 PM

It should be BEFORE

Oops! The SendRichMail line should be BEFORE the return line. I mistyped. I need to get more sleep. The sequence should be:

SendRichMail('smtp.yourisp.com', 'receive@yourdomain.com', 'The input is NULL', ' ', "", 'send@yoursite.com');
return ($::FAILURE,
"The input is NULL No data has been received." .
" This may be due to a known bug in a Microsoft run time file." .
" The bug along with the solution is described <a href='http://support.microsoft.com/default.aspx?kbid=831167'
target=_blank>" ."here</a>.", '', '', 0, 0);

Adding a non-existent image is an excellent idea.

I may not be a good test case. The article says that a workaround is to increase the HTTP keep-alive timeout interval on the Web server or the proxy server. I did this a time long ago on Apache to fix another problem.

Announcement

Error: The input is NULL

Error: The input is NULL

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment