|
> Your draft mentions explicitly that an object with
> Content-Disposition: form-data can have the following
> Content-Types:
>
> application/octet-stream
> multipart/mixed
> text/plain and other subtypes to text/
> message/external-body
>
> It is not quite clear whether any other content-types can be included.
Wow, you really like to have things spelled out. It says
"as with all multipart types". Does it need to say that there
are no restrictions?
> Question 1: Can multipart/form-data be recursively embedded
> inside multipart/form-data?
This is not disallowed, but I imagine it might be rare. If I had
received a form result earlier, saved it to disk, and then later
sent it in as a file as part of another form query, this could happen.
> Question 2: Can application/x-url-encoded be embedded
> inside application/form-data?
Same answer. Rare.
> Question 3: Can objects of Content-Type: Message/rfc822 or
> Content-Type: Message/http be embedded inside application/form-data?
Same answer, but rare. If I dragged a message attachment from
a mail message into a 'file upload' box in a form, this might
happen.
> If yes, perhaps one should add
>
> If a complete e-mail message is to be returned, the
> "Content-Type: Message/rfc822" can be embedded within
> multipart/form-data.
This makes no sense to me. What do you mean "a complete e-mail message"?
Forms rarely ask for 'a complete email message', anyway.
> or
>
> If a complete message is to be returned, the
> "Content-Type: Message" can be embedded within
> multipart/form-data.
"message" isn't a valid media type, so I wouldn't recommend that.
> Your draft says:
>
> If the contents of a
> file are returned via filling out a form, then the file input is
> identified as the appropriate media type, if known, or
> "application/octet-stream". If multiple files are to be returned as
> the result of a single form entry, they should be represented as a
> "multipart/mixed" part embedded within the "multipart/form-data".
>
> Maybe one should here add:
>
> If a HTML document including inline objects like images or
> applets is to be returned as the result of a single form
> entry, they should be represented as a "multipart/related"
> part embedded within the "multipart/form-data". Also other
> submodes to multipart may be embedded within the "multipart/
> form-data".
Well, I'm wary of suggesting this; I'd rather avoid too much advice about
how to use "multipart/form-data" except to say what it means if you DO
use it under various circumstances.
> If this is added, references should maybe be added to RFC 2110 or
> to RFC 2110, 2111 and 2112.
I think I would rather avoid making references to all of the things
that _could_ be sent. It just defines a method of sending things.
Larry
|
