Re: Toward Closure on HTML (William M. Perry)
Date: Tue, 5 Apr 1994 20:43:59 --100
Message-id: <m0poEyM-000062C@monolith>
Precedence: bulk
From: (William M. Perry)
To: Multiple recipients of list <>
Subject: Re: Toward Closure on HTML
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1339
Jay C. Weber writes:
>> From: Dave Raggett <>
>> 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.
>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
>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.