Re: Multipart/mixed for many inline images (was Re: Toward Closure on HTML)

• Mail folder: WWW Talk Apr 94-present
• Next message: Robert C. Pettengill: "Proxy cacheing with VMS httpd"
• Previous message: Joseph Wang: "ANNOUNCING: UNIX HTML WYWSIWYG editor prerelease"
• Maybe in reply to: Matt Heffron: "Re: Multipart/mixed for many inline images (was Re: Toward Closure on HTML) "

Errors-To: listmaster@www0.cern.ch
Date: Sun, 10 Apr 1994 03:42:34 --100
Message-id: <199404100139.UAA25555@austin.BSDI.COM>
Errors-To: listmaster@www0.cern.ch
Reply-To: sanders@BSDI.COM
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Tony Sanders <sanders@BSDI.COM>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Multipart/mixed for many inline images (was Re: Toward Closure on HTML) 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Organization: Berkeley Software Design, Inc.
Organization: Berkeley Software Design, Inc.
Content-Length: 1906

Marc VanHeyningen writes:
> The question then becomes one of how the client should express to the
> server the idea of doing multiple things at once.  Here are some
> random thoughts...
I believe that the client should do a normal initial request and the server
will indicate a willingness to do MGET by returning "Public: MGET".  The
client then indicates it's willingness by issuing the MGET request and
tells the server what reply formats it understands in with standard
"Accept:" headers.  There should be a well defined default so that
all clients and servers can talk to each other but we shouldn't rule
out future extensions.

It would go something like this:

client:
    GET whatever HTTP/1.0
    Comment: just a normal request
server:
    HTTP/1.0 200 Document follows
    Accept: [the request formats we accept]
    Public: MGET

    [normal return data for whatever]
client (note that "whatever" in this request should probably be the
same as the above "whatever" for accounting purposes):
    MGET whatever HTTP/1.0
    Accept: [the reply formats we accept]
    Content-type: multipart/mixed

    [the various requests encoded as message/http-request]
server:
    HTTP/1.0 200 Document follows
    Content-type: multipart/mixed

    [the various replys encoded as message/http-reply]

==============

One other issue we **URGENTLY** need to address is returning error responses
for http requests.  I've mentioned this in the past (several times in
fact) and it's been ignored but now that we have caching proxy servers
this has become *very* important (otherwise you have a useless system
that caches error messages forever).

The only solution that I can see is to move clients towards accepting
multipart messages and having servers return them whenever possible.  The
proxy gateways should be setup to always request multipart replies and
convert the data as needed for clients.

--sanders