3 ms·

If i understand long polling right, then it one request which does not end (not connectio) and keeps receiving or sending information. So processing of multiple

If i understand long polling right, then it one request which does not end (not connectio) and keeps receiving or sending information. So processing of multiple headers does not apply.

sb8244 8y ago
Keep-alive connections still require processing a full HTTP request for every request. This is documented in RFC6202 https://tools.ietf.org/html/rfc6202#section-2.2 https://tools.ietf.org/html/rfc6202#section-2.2 The connection overhead is removed but that is only one of the various overheads that exist. edit: I understand your question a bit differently after reflecting on it more. I think you may be saying that 1 connection never ends in long-polling. This is not the case and is only this way if keep-alive is used. Each server->client data exchange happens by "completing" the request and the client is configured to immediately make a new request. This means every message (or groups of messages depending on your tolerances) is a completed HTTP request.
jkarneges 8y ago
As sb8244 explained, long-polling typically refers to the server waiting before responding, and then responding with a complete response in one shot. What you're thinking of, an HTTP response that the server keeps appending to and the client is expected to read and process incrementally, is also a real thing though. This is typically referred to as HTTP streaming. Examples of this would be SSE (text events) or MP3 streaming (audio). (Not to be confused with HTTP Live Streaming (HLS) which is typically not based on any long lived requests at all!)
wst_ 8y ago
Long polling doesn't allow for multiple polls on one connection. What it gives you is an reply only when there is something to reply with. Otherwise it just keeps connection open and waiting. It's a mechanism that mimics push, from the point of view of a client. Here more info: https://stackoverflow.com/questions/12555043/my-understanding-of-http-polling-long-polling-http-streaming-and-websockets https://stackoverflow.com/questions/12555043/my-understandin...
gregmac 8y ago
To send data using long polling, a new http request has to be made, since long polling is basically just a regular http request with a (possibly) very slow server reply. The client can either terminate the connection and make a new one, or make a second parallel request for sending and leave the first waiting for a new server response. I'm actually not sure which is more common (despite implementing apps that can do long polling, I've never paid attention at that level), nor am I entirely sure how this works with keep-alive connections (eg, can you stop waiting and issue a new http request without closing the TCP session?). In all cases, each request from the client involves sending http headers, and if the client is a web browser, there's going to always be a few hundred bytes at least (cookie, referer, accept, user-agent, etc).

If i understand long polling right, then it one request which does not end (not connectio) and keeps receiving or sending information. So processing of multiple headers does not apply.

sb8244 8y ago

Keep-alive connections still require processing a full HTTP request for every request. This is documented in RFC6202 https://tools.ietf.org/html/rfc6202#section-2.2 https://tools.ietf.org/html/rfc6202#section-2.2 The connection overhead is removed but that is only one of the various overheads that exist. edit: I understand your question a bit differently after reflecting on it more. I think you may be saying that 1 connection never ends in long-polling. This is not the case and is only this way if keep-alive is used. Each server->client data exchange happens by "completing" the request and the client is configured to immediately make a new request. This means every message (or groups of messages depending on your tolerances) is a completed HTTP request.

jkarneges 8y ago

As sb8244 explained, long-polling typically refers to the server waiting before responding, and then responding with a complete response in one shot. What you're thinking of, an HTTP response that the server keeps appending to and the client is expected to read and process incrementally, is also a real thing though. This is typically referred to as HTTP streaming. Examples of this would be SSE (text events) or MP3 streaming (audio). (Not to be confused with HTTP Live Streaming (HLS) which is typically not based on any long lived requests at all!)

wst_ 8y ago

Long polling doesn't allow for multiple polls on one connection. What it gives you is an reply only when there is something to reply with. Otherwise it just keeps connection open and waiting. It's a mechanism that mimics push, from the point of view of a client. Here more info: https://stackoverflow.com/questions/12555043/my-understanding-of-http-polling-long-polling-http-streaming-and-websockets https://stackoverflow.com/questions/12555043/my-understandin...

gregmac 8y ago

To send data using long polling, a new http request has to be made, since long polling is basically just a regular http request with a (possibly) very slow server reply. The client can either terminate the connection and make a new one, or make a second parallel request for sending and leave the first waiting for a new server response. I'm actually not sure which is more common (despite implementing apps that can do long polling, I've never paid attention at that level), nor am I entirely sure how this works with keep-alive connections (eg, can you stop waiting and issue a new http request without closing the TCP session?). In all cases, each request from the client involves sending http headers, and if the client is a web browser, there's going to always be a few hundred bytes at least (cookie, referer, accept, user-agent, etc).