ContentDisposition, why only "inline" and "attachment" are legal values ...?

[polterguy]

Sorry for hammering you with questions, but I'm running into an issue, which is that I am trying to create a MIME message according to these specs; http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4

And then I end up with an exception raised by MimeKit, which says; "The disposition is only allowed to be either 'attachment' or 'inline'." since I am trying to set the ContentDisposition to "form-data".

This is probably an edge case, but I am trying to simulate the way a browser would create a "multipart/form-data", such that I can transparently retrieve arguments on the server side, creating a WebService API, capable of sending MIME messages as content, without having to differentiate between a "browser-client" and another server using the same endpoint as a WebService ...

I want to stay as compatible with how ASP.NET would by default handle this as possible, since then I don't have to create "special code" to handle arguments created by MimeKit. When I try on the server-side to retrieve my arguments, using HttpContext.Current.Request.Params, then if I set the ContentDisposition to "inline" or "attachment", then the "key" for my argument is "null", and its value is the whole MimePart, combined with its headers and boundary string.

I think this is due to that it needs to be "form-data" as ContentDisposition of my MIME parts ...

Hence, I think I'll need to be able to use a ContentDisposition which is NOT of neither "inline" nor "attachment", but instead for instance "form-data", such as this demonstrates;http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4

Or ...?

Would it be possible to allow for alternative ContentDispositions, besides "inline" and "attachment" ...?

Or could I fix this with another solution, which does not require "special server-side code", making me forced to differentiate between x-www-urlencoded types of WebService calls and "multipart/form-data" requests ...

[jstedfast]

I can fix the code to allow "form-data". The only values used with email are "inline" and "attachment" which is why it has that restriction currently. It's more of a "prevent the user from blowing his foot off with this sniper rifle I just gave him" feature.

[polterguy]

Great :)
I know the feeling ... ;)

[jstedfast]

I also added a ContentDisposition.FormData string constant. You don't need to use it, it's just a nice convenience thing.

[polterguy]

Great :)
Thx :)
(I wish there was a "like" button on this UX in GitHub, then I wouldn't feel compelled to thanking you with a comment every time you deliver ;)

[jstedfast]

Hah, no worries :-)