They also share assumptions about the content-type as
a separate issue. The client assumes the response to an
ARTICLE command is a message/rfc822 entity, while the
response to a BODY command is text/plain.
So we'll start by throwing out the 7bit restriction and
assuming binary content transfer encoding. Then we need
a new way to terminate entities. It would be nice to
just stick the bytecount in the status message, and then
blast the entity across.
But HTTP includes a format negociation such that the client
doesn't know the content-type of the returned data
until it comes back. The easy way around that is to _enclose_
all entities in message/rfc822 entities, using the
Content-Type header.
So the server would have to
1) compute the headers to enclose the entity in a message
2) compute the length of the new entity (headers + body)
3) send a status message with that bytecount, and finally
4) send the headers and the body entity.
Note that in step 2, everybody has to be consistent about
the fact that newlines count as _2_ characters: CR and LF.
The the client has to
1) read the status message and extract the bytecount
2) slurp up that many bytes
3) find the blank line that separates the header from the body
4) parse the content-type out of the headers
5) process the body based on the bytecount
That's why I ended up mixing the two levels of protocol
(message/rfc822 headers and HTTP+ status messages.) It would
be easier for the server to:
1) send a status message indicating binary transport (but no bytecount)
2) print the enclosing headers as they're computed
3) print one more header that has the bytecount of the body
4) print a blank line separating the header from the body
5) blast bytecount octets of data over the wire
The the client just does:
1) read and parse nice 7bit headers, one at a time.
2) when you get to a blank line, you know the bytecount and
the content-type of the message.
3) slurp up bytecount bytes of data
4) process it according to content-type.
It is somewhat intertwingled, but I still kinda like it.
Dan