Re: File upload in HTML forms

Daniel W. Connolly (connolly@hal.com)
Thu, 29 Sep 1994 09:05:16 -0500

In message <2E8AD45E@MSMAIL.INDY.TCE.COM>, Fisher Mark writes:
>
>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;

This is mixing methaphors. For one thing, you can't call it
multipart/* without using the multipart syntax, including
boundaries. And you can't stick any content-transfer-encoding except
7bit inside multipart/*. The MIME spec frowns on complex encodings
(e.g. base64 wrapped up in base64).

Did you see my proposal for aggregate/mixed etc? This allows
the features you're after.

>4. Force a blank line:
> printf("%c%c", CR, LF);
>between these headers and the packet contents; and

Blech. Parsing of packets is supposed to be quick and dirty.
Don't muck it up with header/body parsing.

>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

Your Packet: header is exactly the Content-Length: header in sheep's
clothing! You're back to the old problem of having to know how big the
body is before you write the headers of the body part.

Dan