Włącz buforowanie obrazu w trybie programowania w Rails 3.1

Question

W trybie programowania Rails 3.1 (w przypadku korzystania z potoku zasobów) obrazy wyświetlane z zasobów/obrazów są podawane z nagłówkiem odpowiedzi "Kontrola pamięci podręcznej: konieczna rewalidacja".

Oznacza to, że Google Chrome (i na pozór tylko Chrome) będzie próbował wielokrotnie ponownie pobierać obrazy - nawet podczas pojedynczego widoku strony. Doprowadziło to do problemów z wszystkimi sposobami manipulowania DOM za pomocą JavaScript. Pośród:

• jQuery UI Draggable niekiedy rysy dramatyczne przesunięcie od kursora myszy
• dodając lub usuwając klasę CSS, który odwołuje się obraz miga lub rozmiar natomiast wniosek obrazu (który zawsze zwróci 304 niezmodyfikowany) jest w toku.
• Dołączanie lub zastępowanie węzłów HTML zawierających obrazy spowoduje zwiększenie liczby pobrań obrazów, co spowoduje, że całe drzewo węzłów pod nimi będzie migać, ponieważ Chrome czeka na odpowiedź 304 dla każdego obrazu.

Całkowicie rozumiem, że jest to uzasadnione zadanie dla serwera programistycznego. Mogę nawet zrozumieć, że odmowa Chrome polegająca na przechowywaniu w pamięci podręcznej obrazu, nawet w widoku pojedynczej strony, jest całkowicie uzasadniona.

Czy istnieje sposób na zmianę nagłówka Kontroli pamięci podręcznej, który Railsy mają zastosowanie do odpowiedzi na obraz w fazie rozwoju?

Aktualizacja: sugerowane przez kilka osób, jeszcze bardziej interesującym pytaniem jest dlaczego Chrome próba ponownego pobrania czasy wielu zdjęć w odsłoną gdy nie ma innych przeglądarek wydaje? (Dlaczego nie powoduje to problemów u innych programistów?)

Aktualizacja x2: Nie zamierzam przedstawiać tego jako odpowiedzi, ponieważ jest to tylko obejście, które okazuje się wystarczające dla moich celów, ale udało się obejść ten problem przez wstępne kompilowanie zasobów, a następnie odrzucenie wstępnie skonfigurowanego CSS & JS. (. To będzie wymagało zębatkami debugowanie być włączony false w development.rb)

rake assets:precompile 
cd public/assets 
find . -name "*.js*" -exec rm -rf {} \; 
find . -name "*.css*" -exec rm -rf {} \; 

Answer 1

http://code.google.com/p/chromium/issues/detail?id=102706

To wydaje się być udokumentowane problem z chromem. Cierpię z tego samego problemu: Dodanie lub usunięcie klasy CSS, która odwołuje się do obrazu, będzie migać lub zmieniać rozmiar, podczas gdy żądanie obrazu (które zawsze zwróci kod 304 niezmodyfikowany) jest w toku.

Answer 2

Jedynym sposobem widziałem manipulować nagłówek Cache-Control do aktywów trwałych jest konfigurując statyczne z:

config.serve_static_assets = true 

config.static_cache_control = "public, max-age=3600" 

Answer 3

Koło zębate albo wysyła nagłówki buforowania, albo rewizyjnie wymusza (patrz the source).

Nie widzę publicznie dostępnych opcji zmiany tego zachowania.

Aby to zmienić, myślę, że będziecie musieli małpować łatki Sprockets.

Prawdopodobnie bardziej interesujące jest to, dlaczego Chrome zachowuje się w ten sposób?

Answer 4

Nie trzeba kompilować aktywa w publicznych/aktywa i usuń * * css js do obrazów cache

można buforować obrazu w szafie, https://github.com/mvj3/rack_image_assets_cache_control