Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Jul 20, 2012 11:27 AM by cam340
Jul 17, 2012 01:13 AM|LINK
In my brief usage of web api for file uploads following the guidance of excellent articles like
this, it appears that the uploaded file is completely buffered into memory before post method in the ApiController is called. Is this accurate and, if so, is there a way to circumvent this? I understand that web api is built by a series of
HttpMessageHandlers which help abstract away the difficulties of web server development but in this case it would be nice regain controller over the post request stream so that it could be handled in a custom fashion.
Jul 17, 2012 03:12 AM|LINK
What you want exactly? And it's better to have it buffered before sending , it's more reliable instead of directly send it as stream.
Jul 17, 2012 03:37 AM|LINK
Do you have a sample project that reproduces the issue? How are you determining that the file is buffered?
Jul 17, 2012 09:12 AM|LINK
you said that so i assumed it's buffered. do one thing , tell me what you want to do , will implement and send it back , if possible. Fine?
Jul 20, 2012 11:27 AM|LINK
To clarify, there are some very good example server-side implementations of handling single and multipart file uploads from a POST call such as
this one. What web api has done is given us a nicely abstracted way to handle incoming requests in, already deserialized into class objects like HttpRequestMessage. To provide all of this abstaction the entire request message must be consumed and parsed
before the HttpRequestMessage can be passed on to one of our methods in an implementatin of ApiController.
This makes sense and is extremely convenient, however in this case I am interested in dealing with the native incoming request stream on the server myself (when it is a file upload POST being received). Instead of writing the uploaded file directly to disk
I am interested in performing data processing on the file stream as it is being received. The benefit here is that the file is not being buffered somewhere unnecessary. If the data processing fails there is no need to continue the file upload from the client.
Also the upload progress that the user sees will include the progress of the data processing. As the example I linked to stands now the file is completely uploaded (observed via wireshark and fiddler), providing a completed upload progress to the user, before
the PostFile method is every called.