actix_multipart: Incorrect field content type defaults

[jacob-pro]

Current Behavior

The Field::content_type() method returns a default of application/octet-stream in the case that it is not present

actix-web/actix-multipart/src/server.rs

Lines 364 to 368 in bd5c0af

	let ct: mime::Mime = headers
	.get(&header::CONTENT_TYPE)
	.and_then(|ct| ct.to_str().ok())
	.and_then(|ct| ct.parse().ok())
	.unwrap_or(mime::APPLICATION_OCTET_STREAM);

Expected Behavior

According to the multipart specification:

Each part MAY have an (optional) "Content-Type" header field, which
defaults to "text/plain". If the contents of a file are to be sent,
the file data SHOULD be labeled with an appropriate media type, if
known, or "application/octet-stream".

So in the case of a text part, then we should actually get a default of "text/plain" and not "application/octet-stream".

Possible Solution

Unfortunately there is no simple way to provide a default, since from the server's perspective it is impossible to tell if the field is a "file" or "text part", this is because the filename parameter is optional even for files:

For form data that represents the content of a file, a name for the
file SHOULD be supplied as well, by using a "filename" parameter of
the Content-Disposition header field. The file name isn't mandatory
for cases where the file name isn't available or is meaningless or
private; this might result, for example, when selection or drag-and-
drop is used or when the form data content is streamed directly from
a device.

Therefore if we want to provide reliable information to library users, the best thing we can do is make Field::content_type() return Option<&Mime> instead, to reflect the true content type that was set by the uploader.

[fakeshadow]

content-type should be optional for sure.

[jacob-pro]

Ok cool, once I've finished working on #2883 (which currently has a work-around) - then I will open a PR to fix this properly