Re: FORM ENCTYPE=multipart/www-form (was: Toward closure on HTML)
wmperry@indiana.edu (William M. Perry)
Errors-To: listmaster@www0.cern.ch
Date: Wed, 6 Apr 1994 19:04:50 --100
Message-id: <m0poa3L-00003xC@monolith>
Errors-To: listmaster@www0.cern.ch
Reply-To: wmperry@indiana.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: wmperry@indiana.edu (William M. Perry)
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: 1350
>
>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.
But who decides when something should be moved from the
application/www-form-url-encoded block to a block of its own? Simply
saying 'only textarea, scribble, audio, and image/*' might not be 100%
accurate. What happens when there is a very long 'text' block? It is
conceivable if someone doesn't put a MAXLENGTH into an <input type=text>
that someone could type in 10000 characters (I believe that was the default
Maxlength attribute).
I just want to get this straight before I implement it. :)
-Bill P.