Proposal: INPUT TYPE=FILE in HTML 2.0

cho@oclc.org (Chung Jen Ho)
Date: Tue, 21 Jun 94 16:48:34 EDT
Message-id: <9406212046.AA07105@cjho>
Reply-To: html-ig@oclc.org
Originator: html-ig@oclc.org
Sender: html-ig@oclc.org
Precedence: bulk
From: cho@oclc.org (Chung Jen Ho)
To: Multiple recipients of list <html-ig@oclc.org>
Subject: Proposal: INPUT TYPE=FILE in HTML 2.0
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Implementation Group
Here is a proposal for an HTML extension:
Topic: Level 2 Features
Proposal: INPUT TYPE=FILE

Proposed type
FILE
     This allows you to enter a file name for passing a local file to the
     server. File is encoded as a part in a multipart MIME transfer document.

The file transfer feature (local to server) is badly needed for colaborative
work through internet, ie. WIT. There were many requests for this feature
in www-talk. Some requests are shown as attached.

Thanks,
Chung-Jen Ho
+------------------------------------------------------------------+
| XSoft,               |  Internet: cho@xsoft.xerox.com            |
| Xerox Corp,          |                                           |
| 3400 Hillview Ave.   |     Voice: (415) 813-7610                 |
| Palo Alto, CA 94304  |       Fax: (415) 813-7394                 |
+------------------------------------------------------------------+

Attachments:
***********************
<TITLE>EMail Msg &lt;9401041703.AA27235@manuel.hpl.hp.com&gt;</TITLE>
<H1>Re: Attaching docs, Virtual images</H1><ADDRESS>Dave_Raggett &lt;dsr@hplb.hpl.hp.com&gt;</ADDRESS>
<UL><LI><B>Mail folder: </B><A HREF="../www-talk-1994q1.index.html#17.html">WWW Talk Jan 94-present</A><LI><B>Next message: </B><A HREF="18.html">dolesa@smtp-gw.spawar.navy.mil: &quot;A/UX Compiling httpd 1.0 &quot;</A><LI><B>Previous message: </B><A HREF="16.html">Tony Sanders: &quot;Re: CGI, semicolons, and so on... &quot;</A></UL>
<PRE>From: Dave_Raggett &lt;dsr@hplb.hpl.hp.com&gt;
Message-id: <A HREF="17.html">&lt;9401041703.AA27235@manuel.hpl.hp.com&gt;</A>
Subject: Re: Attaching docs, Virtual images
To: jer@bagheera.jax.org
Date: Tue, 4 Jan 94 17:03:34 GMT
Cc: www-talk@www0.cern.ch
Mailer: Elm [revision: 66.36.1.1]
Content-Length: 1413
</PRE><PRE>
Joel Richardson writes:

&gt; Can anyone help me with the following two problems?

&gt; 1. In a forms application that we're developing, the bulk of what the
&gt; user must enter usually exists in a text file already. The form can
&gt; include a textarea, of course, but then the user either has to retype
&gt; the data or cut and paste. Neither is particularly attractive. Is there
&gt; a better way to do this currently? (Something like &lt;INPUT TYPE=&quot;attach&quot; ...&gt;
&gt; suggests itself, but far be it from me to suggest yet another feature ! :-)

People have also asked if it will be possible to paste hypertext and
other MIME formats into form fields. We definitely need to migrate forms
to use a multipart MIME based format for transferring data to the server.
I am currently writing up a proposal for this, along with some new ideas
for supporting dynamic forms, whereby the server can send updates together
with a status message to a form as a result of the user clicking a selection
or checkbox. Sending updates avoid the problems inherent in loading an
entirely new document, when you just want to change a few fields.

The &lt;INPUT TYPE=&quot;attach&quot; ...&gt; idea seems a useful addition, which allows
users to enter a local file name. Browsers would have to work out the
appropriate content type to use when encoding the file as a part in a
multipart MIME transfer document. I will include this in the new draft.

Cheers,

Dave Raggett

</PRE>
************************
>From montulli@stat1.cc.ukans.edu  Wed Feb 16 22:27:13 1994
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
Subject: Idea for new form input type
To: www-talk@www0.cern.ch
Date: Wed, 16 Feb 94 15:27:05 CST
X-Mailer: ELM [version 2.3 PL2]
Content-Length: 1989

I have an suggestion for a new form input type that I would
like to input on.

In order to support the posting of large files using form based
machanisms I suggest that a new input type "include-file" (or
something similar) be added.  This new type would be a file
that exists on the local machine whose data would be posted
to the forms server during form submission.  This method
would require the file to be posted using a MIME multipart
message.

The reasons this will be useful are as follows:
* large text files can be sent without having to cut and paste
  them into a textarea window as they are now.
* no memory limits on the size of the file.  (currently all input
  data is held in memory)
* arbitrary binary files can be sent 

The particular reason I would like to see this type is that I would
like to design a forms based database control system to simplify
management of HTTP servers.  Users could use forms to upload their
HTML or binary files up onto the server thereby eliminating the
need for them to either run their own server or know the commands
of the remote server's operating system.  Additional features would
allow editing and deletion of files and other database management
functions.

This should be an easy thing to add to existing browsers since
all the GUI browsers have file selection dialog boxs already in
use.  The difficult part will be revamping the form post method
to use mime multipart messaging.

:lou
************************
>From waterbug@epims1.gsfc.nasa.gov  Fri Feb 18 11:29:02 1994
Date: Fri, 18 Feb 1994 05:27:44 +0500
From: waterbug@epims1.gsfc.nasa.gov (Steve Waterbury)
To: www-talk@www0.cern.ch
Subject: Re: Idea for new form input type
X-Sun-Charset: US-ASCII
Content-Length: 1337



Lou Montulli writes:

> I have an suggestion for a new form input type that I would
> like to input on.
> 
> In order to support the posting of large files using form based
> machanisms I suggest that a new input type "include-file" (or
> something similar) be added.  This new type would be a file
> that exists on the local machine whose data would be posted
> to the forms server during form submission.  This method
> would require the file to be posted using a MIME multipart
> message.
> 
> The reasons this will be useful are as follows:
> * large text files can be sent without having to cut and paste
>   them into a textarea window as they are now.
> * no memory limits on the size of the file.  (currently all input
>   data is held in memory)
> * arbitrary binary files can be sent 

Enthusiastically seconded!!  This capability would be extremely 
useful for some forms applications I would like to implement.  

- Steve Waterbury
***********************
>From satie3@netcom.com  Fri Feb 25 23:35:17 1994
Date: Fri, 25 Feb 1994 14:35:50 -0800
From: satie3@netcom.com (David Parker)
To: rcp@austin.slcs.slb.com, www-talk@www0.cern.ch
Subject: Re: Idea for new form input type
Content-Length: 2600

>Dave,
>>Lou,
>>
>>> In order to support the posting of large files using form based
>>> machanisms I suggest that a new input type "include-file" (or
>..
>>> The reasons this will be useful are as follows:
>>> * large text files can be sent without having to cut and paste
>>>   them into a textarea window as they are now.
>>> * no memory limits on the size of the file.  (currently all input
>>>   data is held in memory)
>>> * arbitrary binary files can be sent
>>
>>Seems good to me, I guess smart browser could also support drag 'n drop.
>>Tim Berners-Lee suggested a while back now, that you should be able to
>>paste (or drag 'n drop) arbitary data into a TEXTAREA field with the
>>browser being responsible for managing the encapsulation when sending
>>it to the server, and also how to present the pasted data to the user.
>>The browser could default to showing the file name and size if it doesn't
>>have any other way of displaying the file/object in the widget.
>>
>>One way of combining the two ideas is for the TEXTAREA widget to show
>>a file menu in addition to the vertical and horizontal scrollbars.
>>Surely this more general approach would be better than a simple file
>>name widget?
>>
>>Dave
>
>This approach would not address the problem of non text files very well.
>Should a CGI script have to be prepared to handle a MS Word document as
>well as ASCII text from a text area field?
>
>Should the form allow the specification of a desired/required MIME content
>type for the file to be named?
>
>Should there be a mechanism for specifying the MIME content type of the
>file to be sent?
====
Rob:

I agree that there is a urgent need for an 'include-file' feature.  As an 
example, I have been beating my head to find a way to reference and 
download self-extracting files.  I _do not_ want to open it or filter it
in any way - only save it locally from a file server.  At this time, I know
of no way to do it.  I think include-file feature would cover this.

This does not have to 'smart.' It could be as simple as a reference to the 
file like the existing URL.

One possible script for this could look like, <A HREF=includefile://...> and
<A HREF=includehttp://...>

There should NOT be a MIME content type for the file: it is too complicated
and defeats the nature of the transfer one is trying to achieve (anonymous
file types).

Regards,

David Parker
*************************