Re: HTTP: T-T-T-Talking about MIME Generation

> On Fri, 16 Dec 1994, Albert Lunde wrote:
> 
> > As I said earlier (while many of you were off at the IETF?), I'm
> > increasingly convinced that HTTP messages are (as the recent spec
> > suggests) MIME-like, not MIME conforming. With so many other
> > deviations from MIME, I suggest we should drop the (rather complex)
> > MIME multi-part structure based on boundaries, etc. and only allow
> > multi-part messages defined by a Content-Length byte count.
> 
> Yeah!  Other than the fact that MIME existed as did tools for processing,
> I have never understood why an 8bit clean protocol like TCP/IP is
> cluttered with the syntax of mail/MIME (a comment was made at the IETF
> that MIME semantics for multiple part content with a new binary syntax
> might make sense).

Expanding on this idea a bit ... I can't find a good definition
of Content-Length: at this hour (If it started out in the MIME
spec it may have vanished in revisions) (so I may not follow
precident) ... but what I'd like to see is something like this:

headers     
Content-Length: count<CR><LF>
counted bytes
counted bytes
counted bytes
<CR><LF>
more headers

The final <CR><LF> would not be counted in the length (and is
present mainly to make life easier for line-oriented parsers.)

In the case of a single-part message, the final <CR><LF>
would be replaced with closing the connection. (Thus degenerating
to current practice.)

(Because I don't have a prior def handy I'm not sure
how to count or not count the initial <CR><LF>. I'd guess it
is not counted.)

We'd still need mechanisms in the headers to distingush what
initial headers applied to the whole transaction, and what
to a single body, and to indicate the presence of recursion
(multi-part stuff in a body section) if we allow it.

-- 
    Albert Lunde                      Albert-Lunde@nwu.edu

Received on Friday, 16 December 1994 00:11:18 UTC