Re: Toward Closure on HTML

William M. Perry (wmperry@indiana.edu)
Tue, 5 Apr 94 13:31 EDT


Jay C. Weber writes:
>
>> From: Dave Raggett <dsr@hplb.hpl.hp.com>
>>
>> What we really need is some work on a MIME multipart/related format
>> for transferring form contents, as the current URL based approach is
>> running out of steam.
>
>Agreed.
>
>We'd probably want to leave FORM method=GET behavior just the way it is,
>and update method=POST.
>
>Support on the server side is easy: CGI scripts accepting POSTs could just
>start branching on the content-type, e.g., processing a new type
>multipart/www-form. A day's worth of hacking.
>
>On the client side, generating multipart/www-form isn't much work
>(factoring out the user interface complexity of supporting image
>scribbles, etc.), but backwards-compatibility is a bear. The only way a
>server can declare format preferences in advance is through anchors,
>really; so the only alternative I see is something like a FORM
>method=POSTMP.
>
>Dave, do you want to try this with your browser? We'll support it on the
>server side.

Does anyone support the ENCTYPE attribute for forms yet? Why not just
define a new ENCTYPE of multipart/www-form, and have the default still be
application/x-www-form-urlencoded? It shouldn't take more than 20 minutes
to implement this on my browser. How should multipart/www-form be defined?
Content-types for each input area?

-Bill P.