Re: FORM ENCTYPE=multipart/www-form (was: Toward closure on HTML)
weber@eit.COM (Jay C. Weber)
Errors-To: listmaster@www0.cern.ch
Date: Wed, 6 Apr 1994 18:48:49 --100
Message-id: <9404061646.AA01982@eit.COM>
Errors-To: listmaster@www0.cern.ch
Reply-To: weber@eit.COM
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: weber@eit.COM (Jay C. Weber)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: FORM ENCTYPE=multipart/www-form (was: Toward closure on HTML)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1337
I got a response that said separate MIME parts per form entry was too
much overhead for text values, while not just use SGML?
The reason we are discussing the use of MIME is because we see form
values soon extending to relatively complex media clips (signatures,
files, snapshots, etc. -- some already supported by ViolaWWW, by
the way). SGML is not suitable for that but MIME is.
So if the multipart/www-form overhead for simple fields is too much,
we need some hybrid. Here's a suggestion:
each part in a multipart/www-form is interpreted as a form field
whose name appears in the Content-id, and value is the part's body
of type specified by an optional Content-type UNLESS the content-type
is an ENCTYPE other than multipart/www-form, which is interpreted as
containing additional form name/value pairs.
E.g.,
COntent-type: multipart/www-form
--foo
Content-type: application/www-form-url-encoded
line1=val1&line2=val2&line3=val3
--foo
Content-id: comments
This is supposed to be some long block of text,
e.g. from a TEXTAREA or file inclusion
--foo
Content-id: sig
Content-type: image/xpm
<lots of bits here>
--foo--
(I said that "catch-all" parts should be an ENCTYPE *other than
multipart/www-form* to reserve the use of recursive multipart/www-forms
for hierarchical forms with hiearchical name spaces.)
Jay