What about:
Security Considerations
None. multipart/form-data introduces no security considerations.
>> Published specification:
>>
>> multipart/form-data contains a series of parts, each of which has
>> a "Name:" header. As with all multipart MIME types, each part has
>> an optional Content-Type which defaults to text/plain.
> This is a little bit wierd. Offhand, I don't know of any thing in
> MIME that allows type-specific body part headers to be defined, or any
> body part that defines such headers. It's not clear that existing
> MIME parsers would support this. Even if they were to support it,
> there's a strong argument to be made that it should be called
> Content-{something}.
What about:
Content-form-field
instead of
Name
> I take it that the Name header is a body part header, that is, it's
> in the same group of headers as the content-type header, like so:
> content-type: multipart/form-data; boundary=foo
> --foo
> content-type: text/plain
> name: xyzzy1
> stuff
> --foo
> content-type: text/plain
> name: xyzzy2
> stuff2
> --foo--
yes, that's the idea.
>> multipart/form-data headers may optionally include a Content-Length
>> header both in the overall reply and in individual components. The
>> content-length is *not* intended as a replacement for the multipart
>> boundary as a way of detecting the end of an individual component.
>> It is *only* supplied as a way forwarning the server of the amount
>> of data coming.
> This is a Bad Idea. There's already a nonstandard Content-Length
> header in use in email, and it's caused a tremendous amount of
> problems. This variant use of Content-Length would only add to the
> confusion. (I assume this would be the length of the canonical form,
> not the encoded form, of the body part.)
The goal wasn't to create a variant use but to adopt whatever
content-length was used for in email and HTTP. (They *are* the same,
aren't they?) In the case where C-T-E is binary (as it is in HTTP),
the canonical form and the encoded form of the body part are the same.