Delivering and caching files in asp.net

Question

The question is - what is an effective way to deliver files to users? Consider an asp.net application which gives an ability to view various files. A kind of image library or web file directory. Key points are:

• user can upload arbitrary files of size <= 10Mb
• files are stored on disk
• files never change
• user can remove a file
• there is a certain access check procedure for accessing a file

So I'd need to find some balance between availability (i.e. caching) and security (i.e. access control).

Currently user issues a request in a form /attachment/{id}, and a controller reads a file from a disk and sends it to a client:

if(HasAccess(user)) {
   var data = File.ReadAllBytes()
   return new FileResult(data);
}

I suspect that's not an optimal way: it involves asp.net application pipeline and uses disks a lot. Can be this way optimized? Can I store such files in Output cache?

Are there other ways (not using Controller) to deliver files which should be considered?

Answer 1

i have worked recently on a web project using asp.net (MVC3) and we had to implement two functionalities including fetching / storing files on / from the web server (file system). One was file upload and download for user-file-exchange and the other was downloading report files (excel, pdf, csv, and so on).

I always tend and try to use the framework with which i am working to its full capacity, before writing something on my own, because i do believe it is (up to 99% ;) very thoroughly planed, created, optimized and tested to solve specific and real problems.

Having said this, you don't have soo many other options anyway, in my opinion. Why would you use ASP.NET and then trying to avoid the controller? The whole integrated security concept will be broken. Also do not forget logging - overriding the OnActionExecuting gives you a lot of power.

For our project we created custom attributes (customizing the frameworks security context) to decorate the controller methods directly like this:

[UserHasAccess(Roles.Download)]
public Attachment(int id)
{ 
    //... 
}

and thus saved the if part in the code, which makes it more clean and readable. Also why would you want to avoid the clean URI convention (asp.net routes) http:/domain.tld/attachment/id and use something more unreadable like http:/domain.tld/getfile.aspx?id=id?

We used also FileResult to deliver the files with the different mime types and to date we never had any problems.

About the caching - i think it does not make sense to cache files from the file system, unless you now exactly which top 25 files will be downloaded the most. Then yes, you could cache them. In our case the access to the FS proved to be bearable, so we do not cache the files.

Answer of the comment

Hi. In my opinion all best practice articles are regarding to the information or the data that is usually dynamically generated or belongs to the site and is unlikely to change (like navigation buttons for example) and not to files stored to the FS for example.

In our project we use caching for the lists we show (that can contain hunderds of items containing information, but not binary data!) and the pages (every page shows a predefined portion of the list). We do not cache files from the FS!

In your use case you have the point user can upload arbitrary files this could mean 1000 files every day. Would you cache them all? 1000 files x 5MB (in average) ~= approx. 5GB. How much memory has your web server? How often would you refresh the cache? Refreshing means again reading...

You could cache the most recent 100 and if the user who downloads the file is lucky enough to download exactly one of the cached files, then you will spare some time and file system access. In generally and statistically (if the file exchange is used a lot) probably not!

Do the math on paper and see it for yourself if its worth it, to cache the files or not.

I hope this clarifies my previous answer. Sorry for bringing the attributes and so, it was background for using the framework.

kind regards, P.