Re: Slow HTTP Responses

Henning G. Schulzrinne (hgs@research.att.com)
Fri, 14 Jan 94 17:37:32 EST


> We've already pointed out that the status protocol should be UDP-based
> anyway. The nice thing about doing it with "Services:" is that you could
> even write a little stand-alone program that sends a packet to the specified
> port and call it from a shell script! That way *every* server can easily
> provide this service if they want. Also, if it's UDP-based then it would
> be faster *and* require less network resources then muxing on a TCP
> connection. It's also far more likely to be correctly implemented in the
> next 10 years, unlike other solutions that involve radically changing
> the nature of HTTP.
>
> And last, but not least, it's an extensible solution.

Keep in mind that UDP means that many behind-a-firewall machines
won't be able to make any use of any UDP-based mechanism.

In general, there seem to be four situations with long waits where
some user indication would be helpful:

- long data transfer (the current numeric indicator in Mosaic handles that,
although a graphical indication would probably be nicer). If I
understand ftp right, the hash marks are generated purely locally,
simply by counting bytes, without any involvement of the other party.

- long search, followed by burst of data (archie model); all
status messages would precede the actual data (no need to send
escape codes, simply more header fields, for example)

- the tough one: bursts of data, interspersed with "think pauses",
probably without any indication how much more work needs to be done.

- one page consisting of text plus inlined images; the current byte
counts give no indication how long it will be until the whole page
is ready since there could be tens of inlined images

>
> --sanders
>