陳舊？方法在rails中。它有什麼作用？

我不理解文檔here 陳舊？方法在rails中。它有什麼作用？

令人困惑的一點是這對於我：爲什麼你在響應中設置etag或last_modified？客戶端是不是發送etag和if-modified-since標題的客戶端？一旦服務器（或代理服務器）收到這些客戶機頭文件，服務器是否檢查資源的etag和修改日期是否匹配？文檔建議請求是從頭開始生成的，而不是數據？另外，爲什麼我們要在響應中設置etag和last_modified？它不是由客戶設置的嗎？

陳舊？（選項）保護設置ETAG和/或LAST_MODIFIED上響應，並檢查它針對客戶端請求。如果請求與提供的選項不匹配，則該請求被認爲是陳舊的，應該從頭開始生成。否則，它是新鮮的，我們不需要產生任何東西和「304未修改」的回覆是發送。

參數：

：ETAG：LAST_MODIFIED：公共默認情況下，Cache-Control頭是私有的，如果你希望你的應用程序是由其他設備（代理緩存）可緩存此項設置爲true。

這是怎麼回事？因此，一些客戶端請求使用etag（一些散列）進來，我們檢查該請求是否與我們使用陳舊的控制器中的選項相同。這裏是我的控制器：

format.json_v20150501 do 
      expires_in 30.minutes, public: true 
      if stale?(last_modified: last_modified_for_models(recipes), etag: etag_for_models(recipes)) 
      render json: recipes, 
       compact: true, 
       serializer: PaginationSerializer, 
       each_serializer: Api::V20150315::RecipeSerializer 
      end 
     end

我不明白髮生了什麼......

來源

2016-03-11 Jwan622

我回答這一個你張貼另一個問題。就像它說的，陳舊？檢查提供的選項（這些參數）以確定對象是否已被修改，因此需要重新生成。 – toddmetheny

這可能是有益的：etags。 http://blog.bigbinary.com/2016/03/08/rails-5-switches-from-strong-etags-to-weak-tags.html?utm_source=rubyweekly&utm_medium=email – toddmetheny

編輯我的問題。你們可以寫一個答案，我會完全接受它！ – Jwan622

陳舊？檢查提供的選項（這些參數）以確定對象是否已被修改，因此需要重新生成（在緩存的情況下）。

有關的ETag，讀這可能會有所幫助：http://blog.bigbinary.com/2016/03/08/rails-5-switches-from-strong-etags-to-weak-tags.html?utm_source=rubyweekly&utm_medium=email

來源

2016-03-12 21:49:55 toddmetheny

它是什麼檢查選項？ – Jwan622

針對緩存的數據。這就是它檢查上次修改時間的原因。 – toddmetheny

咦？這意味着rails端點在這裏檢查它使用緩存數據生成的選項（args）嗎？ Rails是否檢查它在請求中生成的選項？ – Jwan622

陳舊？方法在rails中。它有什麼作用？

回答

相關問題