[DGD] DGD http daemon?

[Bart van Leeuwen]

On Wed, 9 Feb 2005, Josh Dady wrote:

>
> On Feb 8, 2005, at 6:29 PM, Joakim Romland wrote:
>
> > Either way, you can do some trickery with the xmlHttp object that is
> > available in most browsers these days. But as always with HTTP, you
> > need to do polling to get new state. Although, if you have support for
> > keep-alive sessions in your httpd you poll through the same connection
> > all the time (if you poll more often than the timeout is set to that
> > is).
>
> If the server response is multipart/mixed, it can send the next part
> whenever it wants (without you asking for it first; search
> httpd.apache.org for non-parsed headers).  The problem then becomes one
> of your packets, instead of the server's; is it valid HTTP to send a
> multipart/mixed request and start getting packets of the
> multipart/mixed response before you've completed your request?  I don't
> know, but I doubt it.  Even if it is valid, how many proxies do you
> think have a smoke test on that behavior?

Well, I don't think you'd be getting anything before your initial request,
and any multipart replies following can still be an answer to that
one. What this assumes however is that the connection stays open till you
have sent all parts (which means as long as the user stays online) and
that you do not use that same connection to do new (pipelined) requests
while still getting answers to your initial request (tho silently ignoring
them may just work, it will still cause delay for the client)

I wonder about how reliable this is. Unless you are talking about a server
and client that are written for it specifically, I found that counting on
HTTP connections to last beyond the scope of a single request/reply or a
time beyond a few minutes, is a very good way to add some nice random
unreliability :)

Bart.