Re: Gopher+ Considered Harmful
Thu, 10 Dec 1992 10:55:24 +0100

I once explained the current HTTP protocol to a local network guru and
he expressed concern that basing a protocol like this on TCP/IP is a
great waste of network resources, since you are using a
session-oriented protocol for what is essentially one remote procedure
call. My question "then what would you recommend instead" provoked no
useful answer (what is needed is *reliable* datagrams, but these are
not implemented as an IP protocol; UDP requires too much coding for
time-out, retransmission and fragmentation). Yet, he convinced me
that a light-weight protocol like this should minimize the number of

I have the feeling that the current trend of basing the new protocol
on NNTP violates that requirement. I like the idea of borrowing
response and data formats from the FTP/SMTP/NNTP family of protocols,
with suitable extensions for 8-bit data paths. However I don't like
it if compatibility with NNTP forces us to have an extra round trip
just so that the server can give its welcome message.

Also, I don't like the fact that you must parse the RFC822/MIME header
to find out how many bytes are to be expected. This seems to be
mixing two levels of protocols: MIME assumes that the end of the
message is already known, and the MIME headers then tell you what to
do with it.

As I see it, there are two possible ways of using MIME in HTTP+. We
can either support MIME as the *only* data format (implementing any
extensions we need as new MIME content types or subtypes or additional
headers), or we we support MIME as one of the possible data formats.

In both cases we need a way to indicate how much data follows; if all
we ever send is MIME, all that is needed is a header indicating the
byte count, otherwise a type identifier is needed as well.

--Guido van Rossum, CWI, Amsterdam <>
"The plumage don't enter into it. He's stone dead!"