Re: Slow HTTP Responses
Larry Masinter <masinter@parc.xerox.com>
To: www-talk@www0.cern.ch
In-reply-to: Jon E. Mittelhauser's message of Fri, 14 Jan 1994 15:09:21 -0800 <9401142309.AA01717@void.ncsa.uiuc.edu>
Subject: Re: Slow HTTP Responses
From: Larry Masinter <masinter@parc.xerox.com>
Sender: Larry Masinter <masinter@parc.xerox.com>
Fake-Sender: masinter@parc.xerox.com
Message-id: <94Jan14.171144pst.2732@golden.parc.xerox.com>
Date: Fri, 14 Jan 1994 17:11:44 PST
Content-Length: 967
I wasn't joking, and so didn't include a smiley. Using in-band status
information is most appropriate when the data stream *isn't* binary,
but it is just as possible to add escape codes to a binary gif stream
as it is to on the fly LZW compress a .tar file.
It is neither crazy nor impractical; it uses little additional
bandwidth, or processing speed, doesn't rely on the TCP transport,
works through proxy gateways, doesn't require the client to fork a
separate process to listen for asynchronous UDP packets.
Certainly, for static data that is precomputed, you WOULDN'T want to
use inline escape codes, since you can merely tell the client how big
it is in the first place. This would only be appropriate for those
HTTP requests that were actually computing something where the size of
result and time of completion weren't known in advance.
I admit that there is a perspective from which this is unaesthetic,
but I suggest you squint at it a little harder.