Re: Toward Closure on HTML
montulli@stat1.cc.ukans.edu (Lou Montulli)
Errors-To: listmaster@www0.cern.ch
Date: Tue, 5 Apr 1994 20:31:22 --100
Message-id: <9404051820.AA28274@stat1.cc.ukans.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: montulli@stat1.cc.ukans.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
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
X-Mailer: ELM [version 2.3 PL2]
X-Mailer: ELM [version 2.3 PL2]
Content-Length: 1274
>
>
> > 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.
>
There is already a way to define the encoding type. There is an
attribute to the FORM tag called ENCTYPE that is supposed to
specify the post content type. Right now the only valid option
is "application/x-www-form-urlencoded" but we can easily add
mime/multipart.
:lou
--
Montulli@ukanaix.cc.ukans.edu
913/864-0436
University of Kansas
Lawrence, KS 66045 USA