Dlaczego Chrome korzysta z pamięci podręcznej klienta inaczej w tych dwóch scenariuszach?

Question

Pracuję nad małą jednostronicową aplikacją przy użyciu HTML5. Jedną z funkcji jest wyświetlanie dokumentów PDF osadzonych na stronie, które można wybrać z listy.

NOw Staram się, aby Chrome (początkowo, a następnie wszystkie inne nowoczesne przeglądarki) korzystał z lokalnej pamięci podręcznej klienta, aby wypełnić proste żądanie GET dla dokumentów PDF bez przechodzenia przez serwer (inaczej niż za pierwszym razem oczywiście). Powoduje, że żądam pliku PDF, ustawiając właściwość "data" na elemencie <object> w kodzie HTML.

Znalazłem working example for XMLHttpRequest (nie <object>). Jeśli używasz narzędzi deweloperskich Chrome (karta sieciowa) można zobaczyć, że pierwszy wniosek trafia do serwera i powoduje reakcję z tymi nagłówkami:

Cache-Control:public,Public 
Content-Encoding:gzip 
Content-Length:130 
Content-Type:text/plain; charset=utf-8 
Date:Tue, 03 Jul 2012 20:34:15 GMT 
Expires:Tue, 03 Jul 2012 20:35:15 GMT 
Last-Modified:Tue, 03 Jul 2012 20:34:15 GMT 
Server:Microsoft-IIS/7.5 
Vary:Accept-Encoding 

Drugi wniosek jest serwowane w lokalnej pamięci podręcznej bez serwera w obie strony, czego chcę.

Powrót w moim wniosku, że następnie wykorzystywane ASP NET MVC-4 i ustawić

[OutputCache(Duration=60)] 

na moim kontrolera. Pierwszy wniosek do regulatora - z URL http://localhost:63035/?doi=10.1155/2007/98732 skutkuje następującymi nagłówkami:

Cache-Control:public, max-age=60, s-maxage=0 
Content-Length:238727 
Content-Type:application/pdf 
Date:Tue, 03 Jul 2012 20:45:08 GMT 
Expires:Tue, 03 Jul 2012 20:46:06 GMT 
Last-Modified:Tue, 03 Jul 2012 20:45:06 GMT 
Server:Microsoft-IIS/8.0 
Vary:* 

Drugi Wyniki wniosek w innej obie strony do serwera, o wiele szybszą reakcję (sugerujące buforowanie po stronie serwera?), Ale zwraca 200 OK, a te nagłówki:

Cache-Control:public, max-age=53, s-maxage=0 
Content-Length:238727 
Content-Type:application/pdf 
Date:Tue, 03 Jul 2012 20:45:13 GMT 
Expires:Tue, 03 Jul 2012 20:46:06 GMT 
Last-Modified:Tue, 03 Jul 2012 20:45:06 GMT 
Server:Microsoft-IIS/8.0 
Vary:* 

trzecia prośba do tych samych wyników URL w kolejnym podroż dookoła i odpowiedzi 304 z tych nagłówków:

Cache-Control:public, max-age=33, s-maxage=0 
Date:Tue, 03 Jul 2012 20:45:33 GMT 
Expires:Tue, 03 Jul 2012 20:46:06 GMT 
Last-Modified:Tue, 03 Jul 2012 20:45:06 GMT 
Server:Microsoft-IIS/8.0 
Vary:* 

Moje pytanie brzmi:, w jaki sposób ustawić atrybut OutputCache, aby uzyskać pożądane zachowanie (tj. Żądania PDF są wypełniane z pamięci podręcznej klienta w ciągu X sekund od pierwotnego żądania?

Czy nie robię tego poprawnie, gdy wyświetlam plik PDF, ustawiając właściwość "data" na elemencie <object>?

Answer 1

Czy próbowałeś ustawiać właściwość lokalizację OutputCache do „Klient”

[OutputCache(Duration=60, Location = OutputCacheLocation.Client)] 

Domyślnie właściwość lokalizacja jest ustawiony na „Każdy”, co może oznaczać, że odpowiedź jest buforowane na kliencie, na zasadzie proxy lub na serwerze.

więcej na MSDN OutputCacheLocation

Answer 2

Klienci są zobowiązani nigdy do pamięci podręcznej. Każda przeglądarka może używać własnej heurystyki, aby zdecydować, czy warto buforować obiekt. W końcu jakiekolwiek użycie pamięci podręcznej "konkuruje" z innymi zastosowaniami pamięci podręcznej.

Buforowanie nie jest zaprojektowane do gwarancja szybka odpowiedź; jest zaprojektowany tak, aby średnio zwiększać prawdopodobieństwo, że często używanych zasobów, które nie zmieniają się już tam będzie.To, co próbujesz zrobić, nie jest tym, do czego są zaprojektowane pamięci podręczne.

Na podstawie wyników, które zgłosiłeś, wersja Chrome, z której korzystałeś w 2012 roku, zdecydowała, że ​​nie ma sensu buforowanie obiektu, który wygasłby w ciągu 60 sekund, a prośba została udzielona tylko raz. Więc wyrzucił pierwszą kopię, po użyciu. Potem zapytałeś po raz drugi i zaczął nadawać temu adresowi URL nieco większy priorytet - musiał pamiętać ostatnie adresy URL i zauważył, że to była druga prośba - przechowywał kopię w pamięci podręcznej, ale kiedy nadszedł trzeci wniosek , poprosił serwer o sprawdzenie, czy jest on nadal ważny (prawdopodobnie dlatego, że czas wygaśnięcia był oddalony o kilka sekund). Serwer powiedział "304 - bez modyfikacji - użyj kopii, którą zapisałeś w pamięci podręcznej". NIE wysłał ponownie pdf.

IMHO, to było rozsądne zachowanie pamięci podręcznej dla obiektu, który wkrótce wygaśnie.

---

Jeśli chcesz zwiększyć szanse, że PDF będzie trzymać się dłużej, następnie dać późniejszy czas ważności, ale mówią, że musi skontaktować się z serwerem w celu sprawdzenia, czy jest nadal ważny.

Jeśli używany jest nagłówek HTTP Cache-Control, może to być: private, max-age: 3600, must-revalidate. Dzięki temu powinieneś zobaczyć w obie strony serwer, który da 304 odpowiedź, o ile strona jest ważna. Powinno to być szybką odpowiedzią, ponieważ nie jest wysyłana żadna odpowiedź - używana jest wersja z pamięci podręcznej przeglądarki.

private jest opcjonalna - nie związane z tym zachowania buforowania - Zakładam, że niezależnie od tego lotny PDF jest, to ma sens tylko dla danego użytkownika i/lub nie powinny być wiszące od dłuższego czasu, w pewna wspólna lokalizacja.

---

Jeśli naprawdę potrzebują wydajności nie rozmawia się z serwerem w ogóle, a następnie rozważyć pisanie javascript, aby ukryć/pokazać elementu DOM uznając, że PDF, raczej niż upuszczenie go i konieczności poprosić o nią jeszcze raz.

Twój kod JavaScript dla strony jest jedynym miejscem, które "rozumie", że naprawdę chcesz, aby ten plik PDF się trzymał, nawet jeśli nie wyświetlasz go użytkownikowi.