View Full Version : Why sometimes AJAX have empty $_POST and http://input?

Artem Garashko
25 Mar 2010, 1:08 PM
We recently implemented Ext.Ajax into our software and meet the next problem.

We have the issue that we trying to figure out for a week. We still have no ideas what's the cause.

We submiting the information to the server (currency, rate) and the server returns the result (calculated USD Value, Fee, Total) for the transaction.

Most of the time everything works well. When we was developing it we never had any issues.

But since we deployed Ext.Ajax to production environment, we started to receive very often the complains from users that sometimes the software logs them out.

We started investigating the problem and found out that when it happens, our PHP server gets empty $_POST and php://input (http://input) which suppose to contain SID (session id) (and some other data) and that's why users are being logged out.

Inside the office (where is the server located) it is very hard to recreate the error, but sometimes (very rarely) someone complains.

However, when I use my 3G card internet, I can re-create the error easily by making very quickly many changes on the form.

Also, customers with IE6 have this problem more often.

We use mod_rewrite for Apache.
ExtJS 3.0.3.

We tried everything that suggested here:

This is driving me crazy.:(>:):((:D

Any ideas what can be the cause? Or how to fix it?

P.S. Pardon me for my English, if there is any mistakes.

Artem Garashko
25 Mar 2010, 1:11 PM
Not sure if it is the same problem or not. Even before we implemented Ext.Ajax module into our website, some users complained that sometimes they get logged out for no reason.

25 Mar 2010, 10:24 PM
How frequent are the Ajax requests? Are they really firing off very fast through a loop?

Artem Garashko
26 Mar 2010, 7:23 AM

Not through the loop, but can be 2-5 in one second per user, depends how fast user works with the form. Usually about 25-35 users online.

User selects currency from drop down box - first request, he enters the amount - second, he can add the second line - third, override the rate - fourth, and so on. We sort request by time and display the latest one.

26 Mar 2010, 7:26 AM
That is not a good design. The communication needs to be batched.

You could do this by implementing your comms in a http://www.extjs.com/deploy/dev/docs/?class=Ext.util.DelayedTask

The servlet (or whatever server side technology you have) will have to be able to handle either single requests or Arrays (I assume you are sending JSON)

Artem Garashko
26 Mar 2010, 7:51 AM
Thank you, Animal, but I don't see yet how it can help us.

Any ideas why $_POST is empty sometimes?

26 Mar 2010, 7:57 AM
Do these requests need to be in serial? Does the content of one request depend on the response of a previous?

Artem Garashko
26 Mar 2010, 8:22 AM
Requests don't need to be in serial and don't need to depend on the response of a previous request, however, if an user will be changing different fields too fast, he may lose some entered data, because it will be replaced with the data from previous requests.

26 Mar 2010, 8:27 AM
It sounds like you really have to batch the requests as I suggested. Using a DelayedTask helps in this.

Artem Garashko
27 Mar 2010, 5:00 AM
Thank you for this. What you're suggesting is to reduce the amount of requests. I don't think that will fix the problem.

First - even if it will fix the problem right now, we still will have problems in future, as users base will grow up, therefore the amount of requests will grow too.

Second - obviously, it is have to be something different. The requests are reaching the server and PHP, the problem is that $_POST and php://input is empty. Apache, PHP and SSL logs doesn't have any errors.

I want to find the cause of the problem. I have no idea yet, if it is Apache, browser, or ExtJS problem.

I hope that someone ever had similar problem and he/she may notice this topic.

28 Mar 2010, 12:41 PM
Yes, I am suggesting that. Not only the overall number of requests, but importantly the requests per browser, because they have a limit.

But in the matter of the overall number of requests and a growing user base. The design you appear to be following seems to indicate that your app will not scale, and will overload any server.

Artem Garashko
30 Mar 2010, 7:23 AM
Hi. Very interesting. Thank you for this. We added next fix. If a request is failed, we send another; and four times like this. If the last one is failed, we redirect user to the login page. We'll see how that will workout. Also, we added Loading Icon when a browser waits on the server, however, user still can keep working with the form.

Do you know how many requests is there in IE8/IE7/IE6/Firefox?

Artem Garashko
2 Apr 2010, 7:44 AM
Just wanted to update the topic.

The problem is somewhere else. This logout problem happens not only with AJAX requests.

Even when the users travels from one page to another (which doesn't have AJAX at all), sometimes the system kick him out.

We add SID to each link and sometimes all POST data is just missing and the app provides the new SID.

It happens with the users from outside the network as well as with the users inside the network (less frequent).

Any ideas what it could be?

2 Apr 2010, 8:30 AM
if possible i would make a local copy on your computer or on another server. It sounds more like a server configuration problem.
Maybe a quota? This leads also to the problem that tmp data couldn't be written.

6 Apr 2010, 7:27 AM
Please see this topic. We actually don't use PHP's sessions.

6 Apr 2010, 10:13 AM
method: 'post',
url: 'whaver.php',
params: { SID: Ext.util.Cookies.get('SID'), ... /* rest of params */ },
success: function(response) {
failure: function() {

Mike Robinson
7 Apr 2010, 9:20 AM
:> Trust me ... if Animal says something to you, listen up.

It seems very clear that: (a) your problem is load-related, and (b) the present design of your application will generate a lot of load. (What one guy called "a copper wire tennis-match.")

Let's say you're dealing with a traffic-load of 25 messages per second. With your design you're exchanging 25 messages to do that. If the host "fumbles the ball," it all falls down.

But if you simply set up a delayedTask to do the actual transmission, you achieve a predictable amount of network-traffic no matter what your request pattern is. A delayed task that fires twice per second (usually plenty good enough...) will send no more than two messages per second, each one therefore containing a varying amount of information. There might be 15 messages in the first payload and 10 messages in the second. And yet: it's still achieving a throughput of "25 messages per second."

Notice that the delayed-task is initiated by the first request, yet it waits half-a-second before launching the first actual exchange, in the hope that more outbound records will have accumulated during that interval. Records continue to accumulate in the outbound queue, and the delayed task continues to send them to the host ... in manageable amounts, at a predictable rate, no matter what.

This addresses your host-side problem by changing the behavior-pattern of the client... an "engine governor," if you will. And, you'll notice that more information gets sent overall, because the protocol overhead of HTTP is actually pretty high. The application will be perceptibly more reliable and predictable and your present issues will probably vanish for good.