Re: FORM ENCTYPE=multipart/www-form (was: Toward closure on HTML)
William M. Perry ([email protected])
Wed, 6 Apr 94 12:02 EDT
>
>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.