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

Marc Salomon writes:

> 3. Operating under the assumption that at this time in the life cycle of the
> web, most HTML documents contain components that reside on the same server as 
> the document itself, why not trade the multiple network connections from the 
> client to the same server for some up-front packaging by the server.

Because it defeats caching.  Besides, some people may want to use MIME
multipart types on HTTP for other reasons -- why should the server treat
them any differently than other content types?  [just server here -- I know
why clients would want to do so]

> 6. Interoperating efficiently with client cache management brings up some
> interesting issues.  The ability to check the HTML document's requirements
> against the client-side cache before issuing a precisely tailored HTTP MGET 
> request (which would be returned as multipart/mixed*).

It's much easier to just keep the connection open (with possibly a very
short timeout as defined by the server) and respond with multiple responses
(each one of which may be a multipart entity).

> 7. An instance of the proposed MIME encoding scheme for HTTP follows.  This 
> is currently in the process of a feasibility study in METHADONE (Mime
> Encoding 
> THreAded Daemon Optimized for Network Efficiency), a caching, lightweight
> threaded, MIME multipart encoding HTTP server for solaris 2.x (exploiting the 
> rich base functionality of NCSA's httpd) currently under beta development at 
> the UCSF Library and Center for Knowedge Management.

Sounds like fun, but that's not the hard part.  Serving up MIME multipart
is not the problem.  What you need to do is get clients to understand
(and parse) MIME multiparts.  And that means ALL clients.

> Message-ID: <http://host.domain/http_mime.html>

This is an invalid use of Message-ID -- it must be unique.

> Content-ID: <http://host.domain/path/http_mime.html>

This is an invalid use of Content-ID -- it must be unique.

And what do you do about Content-Encoding?  It's not valid MIME at all.

> Two consecutive boundary strings indicate an EOF.

What?  See RFC 1521.  Or, for that matter, read the HTTP/1.0 draft -- it
already defines EObody-part and EOentity for Multipart entities.

> 8.  I plan to bring this up on the sgml-internet list as well, for a broader,
> more general perspective.

They already want to ship SGML as a multipart/mixed -- adding a bunch of
HTTP-specific controls to it just mucks-up things for the mail people.


......Roy Fielding   ICS Grad Student, University of California, Irvine  USA
                                     <fielding@ics.uci.edu>
                     <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>

Received on Friday, 16 December 1994 20:31:37 UTC