Firstly, I would suggest to wrap this statement in try catch
, as shown here: Sending HTML Form Data.
// Check if the request contains multipart/form-data.
if (!Request.Content.IsMimeMultipartContent())
{
throw new HttpResponseException(HttpStatusCode.UnsupportedMediaType);
}
string root = HttpContext.Current.Server.MapPath("~/App_Data");
var provider = new MultipartFormDataStreamProvider(root);
try
{
// Read the form data.
await Request.Content.ReadAsMultipartAsync(provider);
// TODO ... process files
return Request.CreateResponse(HttpStatusCode.OK);
}
catch (System.Exception e)
{
return Request.CreateErrorResponse(HttpStatusCode.InternalServerError, e);
}
Why to use explicit try catch? We never now who and how will assemble the http request (Browser, Fiddler, third-party tool) ... and the content could be simply damaged, impossible to handle standard way.
The point with Async
content readers is, that we have to read the content, to get the answer:
is there any file included?
That's the way Web API is designed. Read the content only once, only if needed. Before that ... there is no info about the content available.
For example, if there is a request coming from a Browser with a <form>
like this:
<form method="post"
enctype="multipart/form-data"
action="/api/MyService/Upload">
<input type="file" name="myFile"/>
<button type="submit">submit</button>
</form>
Then even in case, that we will just submit (without selecting any file) part of the request body will be:
-----------------------------7de411d9099c
Content-Disposition: form-data; name="myFile"; filename=""
Content-Type: application/octet-stream
-----------------------------7de411d9099c--
So, until we will read we do not know if there is any file