Basic Http Question

[Citydev]

I'm trying to understand precisely how Ajax works and can't find answers in my books or a bit of googling. I am assuming http is a stateless exchange. Connections and exchanges are purely a question of how the processes at each end choose to behave rather than a fundamental feature of http.If a browser makes an http call to a server, I assume it just sends an http message to the URL concerned, marked with Port 80. It then goes into a wait-state and listens for an incoming http message which it then proceeds to render. The first question is what would happen if a message came from another server? The second question is what happens if the target server sends a message and then another message?Now coming on to Ajax, I imagine xmlhttprequest calls some service which allocates a free port number. The browser sends an http message when instructed by JavaScript and sets a up a listner. Again, I'm assuming the only identifiers are the IP addresses and the port numbers ie there is no http exchange identifier. When a message comes in, the browser updates the status values as the message is received, eventually setting readyState to 4 (Complete). Again, what happens if the server sends another message to the same port? Can you set readyState back to 0 - would that get the connection to read any subsequent incoming messages? You can see where I'm coming from - we think of http as a one-out-one-back exchange but if there is no intrinsic control on the sequence then maybe we can override that concept to get a more flexible channel.

[boen_robot]

The HTTP specification desribes most of the cases you're talking about.For your first question (what happens if the message comes from another server?) - This is handled at the TCP/IP state. The client and server estabilish a "socket" one-on-one connection between them. The port on which the server receives the request is defined by the client. If the server is configured to accept calls on that port, it will estabilish a socket connection with the client. The client itself also dictates a port on which it can listen for the response from the server. The socket connection itself can only be used by the two parties involved. Therefore, it's impossible that another server sends in data. What is possible instead though is for the data to be altered along the way by devices which forward TCP/IP packets between the server and the client (e.g. routers, proxies, etc.). Depending on how secure those devices are, data may or may not be altered by hackers. Either way, it makes no difference to the client. You'll see the hacker's data as if it is coming from the server. Still - this is not a concern of HTTP.For your second question (what happens if the target server sends a message and then another message?) - The HTTP specification requires that HTTP responses contain a header called "Content-Length" that specifies the amount of bytes in the HTTP response body, and also specifies that the body starts after two new line characters. Once the body starts, the HTTP client reads only the specified amount of bytes, after which it closes the socket connection. If the server tries to send another message, it won't be able to do it, or if it succeeds (which could happen if the client is too slow in closing the connection), the HTTP client is required to discard all bytes following the specified amount of bytes.Regardless of whether the browser, JavaScript or something else makes an HTTP request, it's done in this very same fashion.The readyState status codes in XMLHttpRequest basically mean (in technical terms):0 = no HTTP interaction1 = preparing HTTP request2 = sending HTTP request3 = waiting for HTTP response or processing the HTTP response4 = HTTP response processed; HTTP socket connection closed.The readyState is supposed to be read only (and read within your onreadystatechange function), so no. It won't change anything... not for good at least though.

[justsomeguy]

You can see where I'm coming from - we think of http as a one-out-one-back exchange but if there is no intrinsic control on the sequence then maybe we can override that concept to get a more flexible channel.

There is intrinsic control, it's built into both the client and the server. If you want to override that, you need to build a new HTTP server and a new client, because according the spec they will both close the connection once it's finished.Think about it like this: if you wanted to build a web application using PHP or whatever else, and you wanted to send one response to the client, then end that response and send another one, how would you do that? No server-side language includes a way to start a new response, the web server does that automatically when it handles the client request. You could open a new socket connection, but that's still a new connection, it's not a continuation of the same request/response. The HTTP protocol is a request/response model, the client makes a request to the server, and the server sends a response. HTTP doesn't allow for anything more than that.There are other stateful protocols, or you can design your own, that's just not what HTTP is.

[Citydev]

The HTTP specification desribes most of the cases you're talking about.

This looks interesting (from 8.1.1):

Pipelining allows a client to make multiple requests without waiting for each response,

[justsomeguy]

I believe that's describing the keep-alive header, in HTTP/1.0 keep-alive was optional, but it's standard in HTTP/1.1. In section 8.1.2.2 it describes pipelining more, but there's not really a technical basis for it, it's just the process of sending more than one request without closing the connection. The only technical basis says that servers are required to send responses in the same order, presumably so that the client knows which response goes with which request. Browsers will already do that for web pages, but I'm not sure if there's a way to do that in ajax. Specifically, I'm not sure what happens then you use the XMLHttpRequest.send method, but I think the browser will immediately send the request without necessarily pipelining it (although if other requests are going out at the same time it might automatically pipeline). You could try using several send calls for the same XHR object and see what happens, but if I remember right once you use send on an XHR object you can't use send again unless you do another call to open, which I assume will open a new connection (and possibly break response handling for the previous request).

[Citydev]

Whilst it would appear the browser can send and receive multiple overlapping messages down the connection, you as programmer are stuck with XMLhttpRequest which, as boen says, seems to only be capable of receiving a message if it's immediately previously sent one, so it seems we're stuck with the server not being able to send a message unless polled, and the application having to always wait for a response when it tells the server anything.

[Synook]

Even though multiple messages can be sent and received with multiple connections being opened, as with pipelining, the browser, as a client, still has to initiate the exchange - the server is incapable of pushing messages out, as there is simply no mechanism in HTTP for it. So yes, if you have to use HTTP, you are stuck with polling.