[6144] in www-talk@info.cern.ch

home help back first fref pref prev next nref lref last post

Re: File upload in HTML forms

daemon@ATHENA.MIT.EDU (Fisher Mark)
Thu Oct 13 09:15:03 1994

Date: Thu, 13 Oct 1994 14:03:55 +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>


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."

home help back first fref pref prev next nref lref last post