I've got a site which allows the consumer to download certain files. However I wish to have a download count for every file so going the typical way by putting the static files on the different subdomain after which letting apache perform the heavy-lifting isn't a way in addition to HttpResponseRedirecting the consumer to some subdomain is not good because then your user 'sees' the correct download url and may therefore download the file without incrementing the download count. I possibly could just develop a view which in turn serve()s the file however am concerned about that "large body fat disclaimer". How does oneOrdo you implement this? I'm quite shure I'm not the only person with this problem.
Concerning the Platform: I'm using apache and mod_wsgi.
We have implemented something where we required to control download use of (largish) static files, naturally not wanting Django for everyone them itself. We emerged having a plan whereby the Django application, after validating the user was permitted to download the file (or increment a counter, inside your situation) we'd produce a at random-named symlink towards the file, which Apache had use of (be cautious: make certain directory indexing is off etc), after which redirect the consumer to that particular symlink to become offered by Apache.
You will find there's "cleanup" cronjob that cleans up symlink one minute after they are produced, therefore if they would like to download it again, they need to undergo Django and also have it counted again. Now, theoretically they might download it more often than once for the reason that time, but is the fact that prone to happen? You can cleanup a lot more than every minute: Apache just needs the symlink to exist at the outset of the download, not through the whole factor.
I'd be curious to understand how others address this issue, as To be sure using the OP that it's a common scenario.
psj's response is certainly one viable option. An alternative choice you need to investigate is placing a reverse-proxy server in-front of apache like Perlbal which assists "X-REPROXY-URL" headers.
After you have overturn-proxy server in position, rather than delivering the consumer a redirect response, you are able to send an answer using the "X-REPROXY-URL" header set to some URL in which the proxy server can access however the user can't. The proxy server will read within the file in the location you submitted the header, after which serve it to your client. They'll achieve this within an efficient way and also, since all of your Django application server must send is really a response having a header set, it's liberated to handle another request.
The simplest method of doing this is by using Apache's X-Sendfile header. Just set the need for the header towards the file path and Apache will be sending the apply for you. This web site publish has more particulars: http://francoisgaudin.com/2011/03/13/serving-static-files-with-apache-while-controlling-access-with-django/ .
Used to do this with django-counter to not sometime ago. Allows you keep an eye on the counts within the admin. http://github.com/svetlyak40wt/django-counter/