Error: The input is NULL

[rmladden]

We should be very angry at Microsoft. Their critical fix 832894 broke a basic IE function. Most people installed it. The fixing fix 831167 is not even on the recommended update list. Like most, my computer only has 832894 installed. Everybody would need to install 831167 manually.

I don't see how Actinic can do much to fix this.

Microsoft recommends this workaround:
Increase the HTTP keep-alive timeout interval on the Web server or the proxy server. There is no setting in Microsoft Internet Information Services (IIS) to control the keep-alive timeout other than the Windows registry KeepAliveTime value. However, some Web servers and some proxy servers could allow you to specify a connection expiration time. If the Web server or the proxy server allows you to change this value, increase the keep-alive timeout interval. See your Web server documentation for the correct setting name and value.

I would urge those with this problem to contact their ISP.

[Mike Hughes]

I agree about microsoft, I went and downloaded all the 'available' updates (critical and non-critical) and as you say this fix isn't even on the recommended list.

Anyone know how to launch a class action suit? They can be forgiven for creating a bug, but not making the fix available sounds like culpable negligence to me.

In terms of monitoring this, my stats for 18 hours over the weekend show that the ratio of orders received to null-input errors is fairly constant at about 2:1.

This doesn't mean that I'm loosing 1/3rd of my orders as I assume people will retry and stand a fair chance of getting through each time. My error logs were playing up so I placed an error image on my site and track that instead (this means I get a proper count of how often the error's being seen, but lose the time and IP information that allows me to compare it with orders received)

The problem is that this is not a repeatable failure and probably depends on server load and the speed of the customers PC and internet connection. Despite several test orders I've been unable to make it fail using my PC and a broadband connection.

It is a major problem though when as many as half my customers are seeing an error (and if it is 50% then that implies 12.5% will see the error 3 times in a row after which I expect them to give up and go elsewhere - and some may give up after just 2 tries).

Maybe the best error message is something along the lines off "Microsoft IE has a bug in the current version that sometimes creates this error. Please go Back and try again"

Mike

P.S. I know Actinic can't fix the problem because it's in the browser, but maybe they could trap the error and try the 'post' again until it works (or give up after 5 tries for example). Another alternative would a message and a 'try again' button on the error page (if the browser has to initiate the post).

[Nadeem]

New Workaround fix for v6, v5 and v4.1.1

Hi there

Attach to this thread is a text file on the workaround for the input is null, its similar to the previous fix, but also applied to the orderscript.pl

Kind Regards

[Mike Hughes]

Thanks Nadeem,

Can you describe for me what the workaround does? I can't tell by looking at the code.

Mike

[rmladden]

I have tried to get the error on my site using two computers that fit the profile and on broadband and dialup. I cannot get it. Since I started trapping the error, it has happened once to somebody, so I know I am not immune. It may be that my long Apache keep alive time (60 seconds) is helping. I have waited for that time to expire between posts, but it still won't happen for me. I also do not use a PSP, so the communications may be simpler. I do use SSL for checkout. I don't have a complete understanding of this problem.

[Mike Hughes]

OK. Re-reading Nadeem's post I get what he's saying. The message about IE being broken will now appear where ever he is when the problem happens.

I assume this isn't the final fix as it doesn't do anything other than tell the customer there's a problem (and by the time the customer has gone to get the fix you've pretty much lost them).

Mike

[cdicken]

Mike

Our hands our tied unfortunately - there is nothing we can do to fix the problem.

The problem (which you can read about at http://support.microsoft.com/default.aspx?kbid=831167) is that if IE fails to do a POST the first time of asking (i.e. going from page to page in the checkout) it will retry, but will retry with blank headers (i.e. no data).

[rmladden]

OK, I think I understand. This is the error scenario:
1. User is browsing the site and clicks checkout.
2. SSL connection is established between the web server and the browser.
3. The web server closes (or resets) the initial connection request because it has not heard from the browser again within the keep alive time. Web servers want the connection closed fast because there is overhead in maintaining it (think thousands of users on busy sites). The default in Apache is 15 seconds. I don’t know what the IIS time is.
4. The user clicks on a button on the web site and the browser tries to send data to the server.
5. Web server says no, you need to re-establish the connection (HTTP protocol).
6. Browser re-establishes the connection, but because of the IE bug forgets to send the data.
7. Actinic gets null post and complains. By this time the data is lost and the web server does not have a way of asking for a re-post.

I have only had the problem trapped once in 24 hours with a lot of activity. I’m betting that setting the keep alive time to 60 seconds works. I think that is past the time that IE expects the session to stay open, so there is never a retry. This would be why Microsoft recommends increasing the keep alive time.

I don’t know if many ISPs will cooperate in changing this setting.

[rmladden]

I spoke to soon. Right after I posted the error happened again.

I am able to test the workaround code by going to os*.pl in my site in the IE address bar (making the request a get so there is no post data). It goes to the first checkout page but it does not display the error box or message. I could not figure out why. I know it entered the workaround code in ValidateInput, but no error message.

Please have the author check the code.

[cdicken]

Bob

Please zip up your amended scripts and send them to me (cdicken [@] actinic.co.uk) and I will have the developer check them over.

[rmladden]

I sent you the scripts. DisplayPage is too complicated for me to figure out.

[Mike Hughes]

Bob,

Good idea of how to test the code.

I just tested mine and it worked fine. As I mentioned somewhere back a few posts, the original fix as posted on this forum had an extra . in it.

Mike

[rmladden]

I checked what I have done many times, but that does not mean much.

I wonder if some setting effects this. The page it goes to for me is the page where it asks for the shipping destination. What page does it go to for you?

[taliesyn]

When I try this for testing, I just get "A General Script Error Occurred". I have applied the patches as specified in Nadeem's post.

Strange

[Mike Hughes]

I realised after posting that you were using the updated workaround whereas I'm still on the original basic one.

All I get with the old workaround is a server error with the error message about microsoft's bug (and my embedded image).

Sorry for any confusion.

What happens with the new workaround? does it forward you to another page?

Mike