> 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