> > Here a diagram: > > Client sends GET -> Server > Server sends HEADERS (Content Encoding: Chunked) -> Client > Server sends chunks -> Client > Client displays them whenever they arrive.
Just one point. If your 'client' is a classical browser it won't work like this out of the box, for the simple reason you have no guarantee the client will do any display before it receive </html> There are provisition in http standard for a progressive display of a page. I can't remember like that the references in http 1.1 specs, just give it a look. It's based on a server pushing of page refreshes on a keep-alive connection. But it need special headers. > > I could just remember the HttpRespone Objects and use one thread, > which gets, when new messages arrive in the queue. The thread then > could println() them to all he HttpRespones. This would save me all > the Threads. Hmm, sounds good, or have I missed somthing?! Yes, one thing, when doGet() returns, the container *could* close the connection. (This is tomcat internal dependent and should not be assumed as deterministic). As a side note, as stated by other people already, you should probably write your own standalone application if you intend to keep all connections alive for your chat. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
