Re: AJAX request hangs for 5 minutes

Thomas 'PointedEars' Lahn wrote:
mouac01@xxxxxxxxx wrote:
"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:

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.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
.

Relevant Pages

  • Re: Broken TCP/IP packets
    ... it a single transaction. ... packets are broken in parts. ... You cannot expect TCP to give you pakets on the remote end the way you ... segments to what ever degree seems good to get a good performance. ...
    (comp.arch.embedded)
  • Re: Broken TCP/IP packets
    ... it a single transaction. ... packets are broken in parts. ... You cannot expect TCP to give you pakets on the remote end the way you ... segments to what ever degree seems good to get a good performance. ...
    (comp.arch.embedded)
  • Re: Broken TCP/IP packets
    ... it a single transaction. ... packets are broken in parts. ... You cannot expect TCP to give you pakets on the remote end the way you ... segments to what ever degree seems good to get a good performance. ...
    (comp.arch.embedded)
  • Re: AJAX request hangs for 5 minutes
    ... It is relevant to the quotation I was referring to, for at least three TCP ... initial SYN and the ACK of the server's SYN. ... In theory, the client could send the request with that ACK, but this ...
    (comp.lang.javascript)
  • Re: embedded gigabit ethernet
    ... That's why TCP is reliable after all. ... > bandwidth the number of not yet acked segments will be impressive. ... > your aquiered data there is no way around local buffering. ... with a strictly local link. ...
    (comp.arch.embedded)