AJAX request hangs for 5 minutes

[mouac01]

My site uses lots of AJAX requests to PHP files which then retrieves
data from MySQL. About 95% of the time the requests complete without
issues. Every once in a while a request will hang for exactly 5
minutes then fail. It seems to be occuring on the client side. I
can't re-create the issue. It just happens randomly. I think it
eventally reaches the server (Apache) because I can see errors in the
server log that certain POST/GET variables are undefined. The
variables are clearly defined. One thing it could be is that it's
only tied to POST requests since I read somewhere that POST makes two
requests to the server. I have this issue with IE6 and IE7 and could
be tied to the wininet.dll I briefly read about as well. I'm not
sure. Below is the typical structure I use for my requests. Any help
will be appreciated. Thanks...

function loginReq(frm){
var req=false;
var msg=document.getElementById("msg");
msg.innerHTML="";
msg.className="error";
if(window.XMLHttpRequest){
req=new XMLHttpRequest();
}else if(window.ActiveXObject){
try{req=new ActiveXObject("Msxml2.XMLHTTP");}catch(e){
try{req=new ActiveXObject("Microsoft.XMLHTTP");}catch(e){}}
}
if(!req){
msg.innerHTML="There was a problem with the request!";
return false;
}
req.onreadystatechange=function(){
if(req.readyState==4){
if(req.status==200){
if(req.responseText.substr(0,1)=='<'){
document.getElementById("main").innerHTML=req.responseText;
}else{
msg.innerHTML=req.responseText;
}
}else{
msg.innerHTML="There was a problem with the request!";
}
}
}
var prm='user='+frm.user.value+'&passwd='+frm.passwd.value;
req.open('POST','login.php',true);
req.setRequestHeader("Content-type","application/x-www-form-
urlencoded");
req.setRequestHeader("Content-length",prm.length);
req.setRequestHeader("Connection","close");
req.send(prm);
}

 

[Michael Wojcik]

It would appear that my former statement applies. The Yahoo! Mail team
obviously does not know how either HTTP or TCP works:

While that quotation is clearly a load of crap - there's no guarantee
that a GET request will be sent in a single TCP segment, for example -
the problem is not how many segments actually get sent (and so the
TCP three-way handshake is beside the point).

Applications present data to the stack. The stack determines how that
data is assembled into TCP segments. It's certainly possible that some
implementations of XHR present POST requests to the stack in pieces
(maybe specifically the request-line and headers in one piece, and the
content-body in another); and that will likely cause most TCP
implementations to usually send the request as two or more segments.

This is indeed undesirable; all associated outbound data should be
presented to the stack at once, whenever possible, to take advantage
of path MTU, reduce overhead, and avoid Nagle / Delayed ACK interaction.

But selecting an HTTP request type based on this possibility is
idiotic. It's a micro-optimization that is likely to have no
observable effect in most cases; Nagle will come into effect if both
segments are smaller than the MSS, but that's only a 200ms delay. And
GET and POST are not equivalent; they are used for different purposes,
so selecting one over the other based on performance is simply wrong.

If a POST request is not idempotent, then replacing it with a GET
request is a violation of the spec.

The TCP *three-way* handshake is one of the first things you learn when
studying computer science.

Nonsense. The three-way handshake, and TCP in general, have nothing to
do with computer science; and it's unlikely that most people studying
computing learn the details of TCP as "one of the first things".

And the three-way handshake is irrelevant here. The HTTP request
itself is not sent as part of the handshake, so a GET request smaller
than the MSS can indeed be sent "with a single TCP packet" (though it
may not be), as the Yahoos claimed, once the conversation is
established. Whether the conversation already exists is extraneous to
the question of how many segments ("packets") are involved in sending
a GET request.

The important point is that GET should be used for idempotent
(loosely, "read-only") requests, and POST for non-idempotent (loosely,
"read-write") requests. The OP should see RFC 2616 - not vapid advice
from random development blogs - for more information.

 

[Thomas 'PointedEars' Lahn]

"The Yahoo! Mail team found that when using XMLHttpRequest, POST is
implemented in the browsers as a two-step process: sending the headers
first, then sending data. So it's best to use GET, which only takes
one TCP packet to send (unless you have a lot of cookies)."

It would appear that my former statement applies. The Yahoo! Mail team
obviously does not know how either HTTP or TCP works:
[...]
The TCP *three-way* handshake is one of the first things you learn when
studying computer science.

Nonsense. The three-way handshake, and TCP in general, have nothing to
do with computer science; and it's unlikely that most people studying
computing learn the details of TCP as "one of the first things".

IBTD, BTDT. YMMV.

And the three-way handshake is irrelevant here. [...]

It is relevant to the quotation I was referring to, for at least three TCP
packets (SYN, ACK, and one containing the actual information) have to be
sent by the client in order to transmit information from the client to the
server via TCP.


PointedEars

 

[Michael Wojcik]

The Yahoo! Mail team could speed that up that by using:

navigator.setSockOpt(IPPROTO_TCP, TCP_NODELAY, 1);

I see your flame bait and raise you a provocation.

I should send them a note.

Using GET, presumably.

 

[Michael Wojcik]

And the three-way handshake is irrelevant here. [...]

It is relevant to the quotation I was referring to, for at least three TCP
packets (SYN, ACK, and one containing the actual information) have to be
sent by the client in order to transmit information from the client to the
server via TCP.

Over the course of the TCP conversation, the client will have to have
performed an active open, which means it will have to have sent the
initial SYN and the ACK of the server's SYN.

In theory, the client could send the request with that ACK, but this
is unlikely to happen in practice. In fact, it's legal to begin a
conversation with a single segment with SYN, FIN, and data; but it's
unlikely that many implementations support that, common APIs don't
give the application any way to request it, and it's technically
forbidden by HTTP anyway. (RFC 2616 is ignorant of TCP half-close and
in effect forbids the client from half-closing its end of the
connection before the response is received.) HTTP should allow
SYN+request, but again it's not likely to happen. (Similarly, we can
ignore experimental variants like T/TCP which avoid the handshake.)

So in practice, yes, there's a three-way handshake to establish the
conversation before the request can be sent, in existing
implementations. And for that matter there will probably be three
segments to close the conversation: a FIN, a FIN/ACK, and an ACK.
Those might be sent with data, but in traces I've done they're
typically empty.

However, that doesn't mean a request takes more than one segment,
because conversation establishment isn't part of the request. It's a
prerequisite for the request, certainly; but then so many things are.
There may have been a DNS request and response, for example. There may
be a conversation with a proxy. There may be Path MTU probing.

If multiple requests are sent over a conversation, then the
conversation overhead is amortized and the cost of each request
approaches one segment.

It's reasonable to construe the original comment ascribed to the Yahoo
Mail team as discussing only the segments carrying actual request
data, and that's a reasonable position to take. Omitting conversation
overhead in that discussion is a simplification, but not an actual error.

What *is* an error is to recommend GET over POST as an optimization,
as they went on to do.

All that said, it was probably good to point out that the Yahoo Mail
comment omitted details such as the three-way handshake, if only to
emphasize to the OP that these things are considerably more
complicated than the Yahoo Mail comment suggested.