2010-09-30 62 views
5

我有一個網站,使用戶可以下載某些文件。但是我想爲每個文件保留一個下載計數,所以按照常規方式將靜態文件放在不同的子域中,然後讓apache完成繁重的工作並不像HttpResponse將用戶重定向到子域一樣好因爲那麼用戶'看到'正確的下載URL並且因此可以下載文件而不遞增下載計數。我可以建立一個視圖然後服務()的文件,但我很擔心那"big fat disclaimer"。你將如何實施這個?我很確定,我不是唯一一個遇到這個問題的人。用django中的邏輯服務靜態文件(保持downloadcount)

關於平臺:我使用apache和mod_wsgi。

謝謝

回答

1

psj的答案絕對是一個可行的選擇。你應該研究的另一個選項是在Apache之前放置一個反向代理服務器,如支持「X-REPROXY-URL」頭的Perlbal

一旦您有了反向代理服務器,您就可以發送一個響應,並將「X-REPROXY-URL」標頭設置爲代理服務器可訪問的URL的響應,而不是向用戶發送重定向響應用戶不能。然後,代理服務器將從您在標題中發送的位置讀入文件,然後將其提供給客戶端。他們會以有效的方式這樣做,並且由於您的所有Django應用服務器需要發送的是帶有標頭集的響應,因此可以自由處理另一個請求。

5

我們已經實現了一個系統,我們需要控制對(大)靜態文件的下載訪問,當然不希望Django自己爲它們服務。我們想出了一個方案,Django應用程序在驗證用戶被允許下載文件(或者增加一個計數器,在你的情況下)之後,我們將爲該文件創建一個隨機命名的符號鏈接,Apache可以訪問該文件注意:確保目錄索引已關閉等),然後將用戶重定向到由Apache提供的符號鏈接。

我們有一個「清理」cronjob,在創建完成後清理符號鏈接一分鐘,所以如果他們想再次下載它,他們必須通過Django並重新計算它。現在,理論上他們可以在那個時候不止一次下載它,但這可能發生嗎?您可以每分鐘清理一次:Apache只需要在下載開始時存在的符號鏈接,而不是整個事情。

我很想知道別人是如何解決這個問題的,因爲我同意OP的看法,這是一種常見的情況。

+0

這聽起來像一個好主意,但我想保持體面的網址設計,並使用戶下載一個文件兩次從相同的位置 – niklasfi 2010-10-01 06:21:30

+0

當然,但這種模式仍然支持。該文件的規範URL是Django控制的URL,它是一致的,體面的等,也是用戶看到的唯一URL。重定向到Apache提供的符號鏈接更多的是用戶不會注意到的「管道細節」 - 瀏覽器遵循透明的重定向。 – psj 2010-10-01 10:04:23