9

From this article on Wikipedia:

Keepalive messages were not officially supported in HTTP 1.0. In HTTP 1.1 all connections are considered persistent, unless declared otherwise.

  • Does this mean that using this mechanism I can actually simulate a TCP socket connection?
  • Using this can I make a Server "push" data to a client?
  • Are all HTTP connections, even the one I am using to connect to Stack Overflow "HTTP persistent"?
  • Does the COMET technology of server push use this mechanism of HTTP persistent connection to push data to clients?
Kevin Boyd
  • 12,121
  • 28
  • 86
  • 128
  • 1
    HTTP persistent connections are just an optimization. There is no behavior difference. If you want to stream data to the client, you can use the chunked encoding, I believe. – derobert Sep 26 '09 at 03:12
  • 1
    @derobert: what is chunked encoding? – Kevin Boyd Sep 26 '09 at 03:58

2 Answers2

10
  • Does this mean that using this mechanism I can actually simulate a TCP socket connection?

Not really, sockets have MANY more features and flexibility.

  • Using this can I make a Server "push" data to a client?

Not directly, it's still a request/response protocol; the persistent connection just means the client can use the same underlying socket to send multiple requests and receive the respective responses.

  • Are all HTTP connections, even the one I am using to connect to Stack Overflow "HTTP persistent"?

Unless your browser (or a peculiar server) says otherwise, yes.

  • Does the COMET technology of server push use this mechanism of HTTP persistent connection to push data to clients?

Kinda (for streaming, at least), but with a lot of whipped cream on top. There are other Comet implementation approaches, such as hidden iframes and AJAX long polling, that may not require persistent connections (which give some firewalls &c the fits anyway;-).

Alex Martelli
  • 854,459
  • 170
  • 1,222
  • 1,395
  • 1
    You say "sockets have MANY more features and flexibility". What are these features vis a vis HTTP persistent connection and what flexibility do they provide? – Kevin Boyd Sep 26 '09 at 03:04
  • 2
    TCP sockets impose no restrictions on who speaks when or how -- either party can send bytes any time without waiting for the other ("full duplex"), the stream is not intrinsically chunked up into messages of defined length, &c. You need a higher-layer protocol on top to give up some of the flexibility and turn chaos to order: HTTP is just one such protocol, an asymmetrical half-duplex request/response protocol with messages of well-defined length (content-length headers or chunking). Client may enqueue requests one after the other, server must respond to each request. – Alex Martelli Sep 26 '09 at 17:34
1

Actually, the HTTP server can "push" data to a connected http client without the client requesting it. See "HTTP server push" at http://en.wikipedia.org/wiki/Push_technology. However it does seem to be commonly implemented.

Michael
  • 91
  • 1
  • 2