Re: Slow HTTP Responses (Jon E. Mittelhauser)
Date: Thu, 13 Jan 94 19:15:04 CST
Message-id: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Tony Sanders <sanders@BSDI.COM>,
From: (Jon E. Mittelhauser)
Subject: Re: Slow HTTP Responses 
Cc: Tim Berners-Lee <>
X-Mailer: <PC Eudora Version 2.0>
Content-Length: 1723
At 05:58 PM 1/13/94 -0600, Tony Sanders wrote:

>It's not clear to me at this point
>that "Status:" is the right solution, HTTP is simply not designed as an
>interactive protocol TTBOMK.

It's fairly clear to me that it is _not_ the correct solution.  I was
thinking along the same lines as Tony w/ regards to using a separate
UDP connection.

Maybe I was just missing something, but I didn't see how either of
the initial suggestions would actually work.  

The first method forced all of the status info to come before any of
the data was transferred which seems silly.  If I have a server 
generating information, it may as well be sending it as it is generated.  

The second method, I don't understand at all. I've already received one 
HTTP/1.0 response so how/where am I getting the "HTTP/1.0 205 Starting 
search..." messages?

>My current thinking on this general problem is that we need "protocol
>callbacks", reply addresses for services provided by the client encoded
>in the client's request to the server.  For example, status messages could
>be passed back via:
>	Services: Status/1.0 port=9994
>Or, you might have the status monitor on another host:
>	Services: Status/1.0 port=9994,host=otherhost.dom
>Or support an interactive audio/video service:
>	Services: AVsync/1.1 port=9995,chn=32,mode=HDTV.3
>The status service should probably be UDP based, another reason
>not to run it inside HTTP.

Agreed.  It is silly to use TCP for information which is obviously
ideally suited for UDP.  


Jon E. Mittelhauser (
Research Programmer, NCSA                          (NCSA Mosaic for MS Windows)
More info <a href="">here</a>