Re: File upload in HTML forms

Fisher Mark (FisherM@is3.indy.tce.com)
Thu, 13 Oct 1994 13:46:31 +0100

1. I finally found Daniel Connolly's "aggregate/mixed" MIME type proposal.
I think that a "Suggested-Name: " or "Aggregate-Part-Name: " header is also
needed as a hint to the CGI script as to what to name each aggregate part.
(A better name for this header would be nice, too :)...) The example
given would then become something like (where lines without leading '>' are
new):

> 0200 document follows
> Content-Type: aggregate/mixed
> Content-Transfer-Encoding: binary
>
> Content-Type: text/html
Suggested-Name: ctm.html
>
> 4000
> ...4000 bytes of stuff...
> 1745
> ...1745 bytes of styff...
> 0
> Content-Type: image/gif
Suggested-Name: Thomson.gif
>
> 4000
> ...4000 bytes of stuff...
> 1745
> ...1745 bytes of styff...
> 0
> .
>

with the proviso that "Suggested-Name: " is just a suggestion which may be
ignored by the CGI script if a name is unnecessary.

2. Ernesto Nebel's proposal for delayed file transmission has this sequence
of actions:

(1) Browser sends GET request for a form
(message from browser to server)
(2) Server sends back HTML form
(message from server to browser)
(3) Browser user fills out form
(4) Browser POSTs or PUTs it back
(message from browser to server)
(5) Server starts CGI script
(6) CGI script reads and evaluates form
(7) CGI script sends back accept/deny response for file xfer
(message from CGI script to browser)
(8) Browser packs up files and sends them to CGI script
(message from browser to CGI script)
(9) CGI script sends success/failure response to browser
(message from CGI script to browser)

where (1)-(2) is the HTTP GET method and (3)-(9) is the proposed HTTP PUT or
POST method for file uploads. Note that the GET method uses a single
"message" from the browser to the server and a single "message" from the
server back to the browser. This number of messages is also the number used
by present-day PUT and POST scripts. The requirement of alternating
multiple messages (4 in (3)-(9)) means the server/CGI script maintain an
implicit state for the connection, as the connection must either persist
until after (9) or (7) must pass back a transaction ID for use in (8)-(9).
It would seem just as easy for the CGI script to receive the files right
away, then report back that not all files were transferred via a new status
code.

The ability in (6) to determine whether there is space available for the
upcoming files depends on either the ability to preallocate the space for
the files or unreliable heuristics (as predicting available disk space
should be at least NP-hard if not NP-complete).
======================================================================
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."