CODEWITHSUNDEEP
c#asp.netbrowserstreamasp.net-web-api2
Lasse Christiansen
Lasse Christiansen

Reputation: 10325

ASP.NET Web API StreamContent - make browser show download progress

From an ASP.NET Web Api 2.x controller I'm am serving files using an instance of the StreamContent type. When a file is requested, its blob is located in the database, and a blob stream is opened. The blob stream is then used as input to a StreamContent instance.

Boiled down, my controller action looks similar to this:

[HttpGet]
[Route("{blobId}")]
public HttpResponseMessage DownloadBlob(int blobId)
{
    // ... find the blob in DB and open the 'myBlobStream' based on the given id

    var result = new HttpResponseMessage(HttpStatusCode.OK)
    {
        Content = new StreamContent(myBlobStream)
    };
    result.Content.Headers.ContentType = new MediaTypeHeaderValue("application/octet-stream");
    result.Content.Headers.ContentLength = myBlobStream.Length;
    result.Content.Headers.ContentDisposition = new ContentDispositionHeaderValue("attachment")
    {
        FileName = "foo.txt",
        Size = myBlobStream.Length
    };
    return result;
}

When I hit the endpoint in Chrome (v. 35) it says that it is resolving the host (localhost) and when the file has downloaded it then appears in the download bar. However, I am wondering what is needed to enable Chrome (or any other browser) to show the download progress?

I thought this would be fixed by included the header information like content-type, content-length, and content-disposition, but from what I have tried, that does not make any difference.

Upvotes: 4

Views: 7955

Answers (2)

Lasse Christiansen
Lasse Christiansen

Reputation: 10325

Turned out that my implementation was correct. I closed fiddler and everything worked as expected. Don't know if fiddler somehow waits for the entire response to complete before it sends it through its proxy - at least, that would explain why the browser stays in the "resolving host" state until the entire file has been downloaded.

Upvotes: 3

djikay
djikay

Reputation: 10638

The Web API doesn't "push" information so, unless you have a background thread on your client polling the server for the download status every few seconds or so, this is a bad idea. For a number of reasons in fact:

  • Increased load on the server to serve multiple requests (imagine if many clients did that at the same time)
  • Increased data communication from your client (would be important if you were doing this on a mobile phone contract)
  • etc. (I'm sure I can think of more but it's late)

You might want to consider SignalR for this, although I'm no expert on it. According to the summary in the page I linked:

ASP.NET SignalR is a new library for ASP.NET developers that makes developing real-time web functionality easy. SignalR allows bi-directional communication between server and client. Servers can now push content to connected clients instantly as it becomes available. SignalR supports Web Sockets, and falls back to other compatible techniques for older browsers. SignalR includes APIs for connection management (for instance, connect and disconnect events), grouping connections, and authorization.

If your Web API can allow it, I suppose a potential alternative would be to first send a quick GET request to receive the size of the file you're about to download and store it in your client. In fact, you could utilise the Content-Length header here to avoid the extra GET. Then do your file download and, while it's happening, your client can report the download progress by comparing how much of the file it has received against the full size of the file it got from the server.

Upvotes: 1

Related Questions