Is it possible to stream realtime HTML?  Do browsers still display even when it hasn't recieved all the HTML code?

Is it possible with servlets (java's answer to asp, cgi, etc)?  I'm having a bit of trouble trying to get to the lower level socket of the http connection.  All I can find are wrapper classes which builds an entire new http response everytime I flush the stream.

Yes, it is possible.

Don't send the content-length header.

At the moment, I'm trying to find a way to send the data in realtime without having the servlet build a brand new HTTP response.  Unfortunately, the HTTP protocol is by nature unidirectional.  Anyone familiar with servlets aware of a way to get the raw HTTP socket connection?  Perhaps this belongs in the java programming forum.

[quote author=Lenny link=topic=10814.msg102625#msg102625 date=1110075158]
At the moment, I'm trying to find a way to send the data in realtime without having the servlet build a brand new HTTP response.  Unfortunately, the HTTP protocol is by nature unidirectional.  Anyone familiar with servlets aware of a way to get the raw HTTP socket connection?  Perhaps this belongs in the java programming forum.
[/quote]

It really depends on what language you're using.  It doesn't belong on the Java forum if you're using ASP, for example.

You can do that with javascript using XMLHttpRequest/XMLHttp, if you want. It allows the client to make background HTTP requests without changing their page. Very useful for highly interactive web pages. I believe gmail uses this method.

Well if I made something such as a chat server, the servlet being the server, I would want a broadcast message to reach the clients once the server itself receives the message.  I would prefer to not have the browser send periodical requests to see if there's a new message available on the server.

Sounds like streaming HTML for the chat window and a frame to send messages would work fine.

That brings me back to the original problem of the servlet building a brand new http response whenever the buffer is flushed (the socket is also closed).  If I can prevent the servlet from building  a new http response, I can stream the data easily over a persistent connection.

What object are you using to generate the response? If you're using something that implements HTTP, I don't think you'll be able to get this working how you want. AFAIK, omitting content-length from your reply isn't a part of the HTTP standard: it's a bit of a hack. You should do this using Socket/ServerSocket, or something that lets you build an HTTP response yourself.

Also be aware that browers usually give up trying to load a page after a while (usually a few minutes (~10-15) in my experience). I have often gone afk from webchannel and found that IE has given up trying to load it - refreshing the page is required to see the latest chat, afer which it will stream again for a while before giving up.

What you need to do is be able to hold the socket and prevent it from flushing and closing.  Combine that with not specifying the content-length header, and until the browser window is closed, you should be able to live-stream HTML.

The server I'm working on no longer allows ServerSockets, I'm looking at GenericServlet right now.  Unlike HttpServlet, GenericServlet isn't protocol specific.

But I am aware if I stream HTTP like this I am breaking its standard convention. ;D

You could use chunked encoding to transfer data streaming?

I read something about this in MSDN Magazine and replicated the process, I'll see if I can find my old work, or the magazine..

[quote]
  All HTTP/1.1 applications that receive entities MUST accept the
  "chunked" transfer-coding (section 3.6), thus allowing this mechanism
  to be used for messages when the message length cannot be determined
  in advance.
[/quote]
http://www.faqs.org/rfcs/rfc2616.html

Well, after testing GenericServlet, I found that it is protocol independent.  But that independence only goes as far as what the server's natural protocol would be.  In this case, it would be http.

Well now that it seems I won't be able to escape http, I might as well attempt to suite it for my needs.  I'll give chunked encoding a try...