Re: Slow HTTP Responses
Tony Sanders <sanders@BSDI.COM>
Message-id: <199401142215.QAA08634@austin.BSDI.COM>
To: www-talk@www0.cern.ch
Subject: Re: Slow HTTP Responses
In-reply-to: Larry Masinter's message of Fri, 14 Jan 1994 13:30:26 PST.
Organization: Berkeley Software Design, Inc.
Date: Fri, 14 Jan 1994 16:15:07 -0600
From: Tony Sanders <sanders@BSDI.COM>
Content-Length: 1501
Larry Masinter writes:
> Telnet already does this by having some escape codes.
Blah, some serious uglyness is due to this. Muxing control information
into a data stream is a very ugly proposition. It's best to let the
low-level protocol code do it since *lots* of people have spent *lots* of
time making that perfect.
> Why not use an escape code mechanism for those information channels
> that want to send status information back? This won't be MOST servers,
> only a few. The client just would have to look for the escape codes in
> the data stream.
It makes the protocol two or three orders of magnitude more complex, which
is exactly what HTTP tries to avoid in the first place. It doesn't matter
if only a few servers need to do it, every client would have to support it
and, for practical reasons, so would most servers.
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.
--sanders