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}.
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--
> 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.)
Keith