Re: Idea for new form input type (Robert C. Pettengill)
Date: Fri, 25 Feb 1994 10:19:46 --100
Message-id: <9402181521.AB21912@genoa>
Precedence: bulk
From: (Robert C. Pettengill)
To: Multiple recipients of list <>
Subject: Re: Idea for new form input type
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1760
>> 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?

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?


Robert C. Pettengill
Schlumberger Lab for Computer Science, P.O. Box 200015, Austin, Texas 78720 Internet, +1 512-331-3728 Voice, +1 512-331-3760 Fax