Re: Toward Closure on HTML
wmperry@indiana.edu (William M. Perry)
Errors-To: listmaster@www0.cern.ch
Date: Tue, 5 Apr 1994 20:43:59 --100
Message-id: <m0poEyM-000062C@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: Toward Closure on HTML
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1339
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.