Re: Slow HTTP Responses

hgs@research.att.com (Henning G. Schulzrinne)
Message-id: <9401142238.AA25720@dxmint.cern.ch>
Date: Fri, 14 Jan 94 17:37:32 EST
From: hgs@research.att.com (Henning G. Schulzrinne)
To: www-talk@www0.cern.ch, sanders@BSDI.COM
Subject: Re: Slow HTTP Responses
Content-Length: 1728

> 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
>