2012-03-29 63 views
4

我一直在試圖獲得在Heroku上的Rails 3.2的流式工作(請參閱我的SO帖子:Rails 3.2 streaming)。可以在Rails 3.2中的每個請求基礎上禁用rack-cache?

我得出結論,機架緩存導致了問題。在production.rb中使用config.middleware.delete(Rack::Cache)禁用它似乎解決了這個問題。很明顯,這對我的整個應用程序都是禁用的。

我只希望它禁用的一個流請求(這是管理端,將不常使用)。這可能嗎?爲了一個小的(但是必需的)管理功能而丟失緩存將會是一個重大的失望。

非常感謝!

編輯:我試圖設置標題不緩存有問題的動作,但Rack :: Cache仍然導致流失敗。完全禁用它是我迄今發現的唯一解決方案。

+0

真正幫助我解決這個問題的其實只是知道你可以使用'config.middleware.delete(「Rack :: Cache」)'來禁用Rack :: Cache。 (P.S .:它需要Rack :: Cache的引用。) – thekingoftruth 2013-09-25 17:17:41

回答

2

我最終不需要禁用Rack-cache。只需要將此self.response.headers['Last-Modified'] = Time.now.ctime.to_s 添加到我的回覆中。

0

雖然你不能禁用它,你可能不需要;你可能只需要繞過緩存機制。

每源herehere,如果Cache-Control: no-cache頭或Pragma: no-cache標頭設置,機架::緩存將不會試圖把從緩存中的請求。這並不會禁用它,但它確實可以確保您沒有不應緩存的請求最終返回緩存響應。

此外,還可以確保機架::緩存,從不緩存爲給定的行動類似的迴應:在你的控制器動作

response.headers['Cache-Control'] = 'private,max-age=0,must-revalidate,no-store' 

。這將確保Rack :: Cache(以及任何其他上游代理)不會緩存響應,從而使您的後端始終保持新鮮感。

如果失敗了,那麼您可能會因context.rb中的forward方法而發生問題。似乎沒有辦法繞過它,所以如果設置了某個標題,你可能想要修補Rack :: Cache來調用#call

+0

不幸的是,似乎設置頭文件並不能解決它。似乎我需要完全取消Rack :: Cache。我會調查你的補丁的想法......任何指示我可能會這樣做?謝謝! – 2012-03-29 22:14:02

+0

你應該放棄最大年齡。從RFC2616開始:如果請求包含no-cache指令,它不應該包含min-fresh,max-stale或max-age。 – zaius 2013-02-05 09:21:10

+0

RFC的那部分適用於請求標頭,而不是響應標頭。 – 2013-02-05 13:00:54

相關問題