[5920] in www-talk@info.cern.ch
Re: File upload in HTML forms
daemon@ATHENA.MIT.EDU (Fisher Mark)
Thu Sep 29 09:27:02 1994
Date: Thu, 29 Sep 1994 14:16:38 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: FisherM@is3.indy.tce.com
From: Fisher Mark <FisherM@is3.indy.tce.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
>I'll be the first to admit that lots of applications need only a
>single file upload, but lots more might want several files. In either
>case, no changes to 'HTTP' are being proposed. Changes to HTML,
>additional MIME types to encapsulate multiple values more efficiently,
>etc.
My mistake; no changes to HTTP are needed.
I like Daniel W. Connolly's "Content-Transfer-Encoding: packet" proposal.
It solves the same problem "Content-Length:" and "boundary=" do without
imposing the requirements either of knowing the length of the content a
priori or of having to scan the data for a boundary. I would make these
additions to it:
1. Have each packet header in the form:
enum { LF=10, CR=13 };
printf("Packet: %d%c%c", bytes, CR, LF);
2. Define "Content-Type: multipart/file; name=X" where X is the suggested
filename for that part. Agents (mail user agents, WWW browsers, etc.) are
free to rename the file as they deem fit or to reject filenames if they
violate filesystem access permissions (like "Content-Type: multipart/file;
name=/etc/passwd");
3. Allow the "Content-Type:" header to occur when a "Packet:" occurs;
4. Force a blank line:
printf("%c%c", CR, LF);
between these headers and the packet contents; and
5. Once a "Content-Type:" header is seen, the following packets up to the
next "Content-Type:" or the end of the message belong to the file/part
specified in the first "Content-Type:".
The resulting data would look like this for two files, each with one line of
text terminated by a CR-LF pair:
Content-Transfer-Encoding: packet
Content-Type: multipart/file; name="capital.txt"
Packet: 28
ABCDEFGHIJKLMNOPQRSTUVWXYZ
Content-Transfer-Encoding: packet
Content-Type: multipart/file; name="lower.txt"
Packet: 28
abcdefghijklmnopqrstuvwxyz
These changes create a new MIME type for transferring multipart messages
(like groups of files) in an 8bit-clean environment. (1) and (3) are just
syntactic sugar that might make it easier to code the necessary
modifications.
If "file=X" was optional for multipart/file, then files could be anonymous
instead of forcing the creating program to come up with random names. Not
sure what the application for this would be, though...
======================================================================
Mark Fisher Thomson Consumer Electronics
fisherm@indy.tce.com Indianapolis, IN
"Just as you should not underestimate the bandwidth of a station wagon
traveling 65 mph filled with 8mm tapes, you should not overestimate
the bandwidth of FTP by mail."
