2016-11-01 35 views
8

W aplikacji ASP.NET Core mam metodę działania, która zwraca niektóre dane. Chciałem buforować te dane po stronie klienta. Tak więc w oparciu o documentation here mogę użyć atrybutu ResponseCache w metodzie akcji. Ten atrybut dodaje Cache-Control nagłówek w odpowiedziAtrybut ResponseCache nie buforuje danych po stronie klienta

buforowanie odpowiedź odnosi się do określania nagłówków związanych z pamięci podręcznej na odpowiedzi HTTP dokonane przez działania ASP.NET MVC rdzenia. Nagłówki te określają, w jaki sposób maszyny klienta i pośrednie (proxy) mają buforować odpowiedzi na odpowiedzi na niektóre żądania (jeśli w ogóle). Może to zmniejszyć liczbę żądań klienta lub serwera proxy do serwera WWW, ponieważ przyszłe żądania z tej samej akcji mogą być obsługiwane z pamięci podręcznej klienta lub proxy z serwera proxy.

również

buforowanie odpowiedzi nie buforuje odpowiedzi na serwerze WWW. To różni się od wyjściowego buforowania, które buforowałoby odpowiedzi w pamięci na serwerze w starszych wersjach ASP.NET i ASP.NET MVC.

Tak to jest jak moja metoda działania wygląda

public class LookupController : Controller 
{ 
    [HttpGet] 
    [ResponseCache(Duration = 120)] 
    public IEnumerable<StateProvinceLookupModel> GetStateProvinces() 
    { 
     return _domain.GetStateProvinces(); 
    } 
} 

potem wywołać metodę przy użyciu przeglądarki jako http://localhost:40004/lookup/getstateprovinces Oto nagłówki żądania i odpowiedzi

enter image description here

Zauważ, że odpowiedzi Nagłówki mają oczekiwane wartości Cache-Control: public,max-age-120. Jednak jeśli odświeżysz stronę za pomocą F5 (przed 120 sekund), punkt przerwania debuggera w metodzie akcji GetStateProvince zawsze trafia. Oznacza to, że nie zawiera danych po stronie klienta.

Czy jest coś jeszcze, co należy zrobić, aby włączyć buforowanie po stronie klienta?

Aktualizacja Próbowałem używać IE, Chrome, a także POSTMAN bez powodzenia. Za każdym razem, gdy wpisuję adres URL w pasku adresu lub odświeżam klienta (czyli przeglądarkę lub listonosza), wywołuje metodę wezwania do działania.

+0

@dotnetstep ma rację, również f5 (odświeżania strony) jest już broker cache po stronie klienta, co wiem. po prostu wprowadź adres w pasku adresu i wprowadź. że sposób, w jaki sprawdzam bufor cache'a – ergen

+0

@ Próbowałem także z POSTMANem bez powodzenia – LP13

+0

Nie wiem kto jest człowiekiem. wyjaśnijmy: spróbuj po prostu otworzyć URL w przeglądarce, zamiast odświeżać. refresh jest brokerem, po drugie, typ pliku jest ważny dla buforowania klienta. na przykład nie przechowujesz pamięci podręcznej o wielkości 1000 MB. buforujesz tylko .json, więc to nie ma znaczenia. wtedy jestem pewien, że pamięć podręczna będzie działała, gdy użyjesz adresu URL, takiego jak licalhost/lookup/getstateprovinces.json. skup się na rozszerzeniu i buforowaniu plików po stronie klienta. nawet jeśli dodasz nagłówek do swojej odpowiedzi, przeglądarka może nie znać Twojego pliku jako pliku statycznego z powodu rozszerzenia – ergen

Odpowiedz

0

Przede wszystkim chcę wyjaśnić kilka rzeczy i jestem pewien, że już to wiedziałeś.

  1. ResponseCache nie jest równa OutputCache w żaden sposób.

  2. ResponseCache jest jak na mój nagłówek zestawu myślenia, ale nie buforuje niczego po stronie serwera.

Teraz Jeśli chcesz cache tak samo jak OutputCache, być może będziesz musiał użyć wersji podglądu 1.1, która właśnie została wydana.

rdzeń ASP.net 1.1 preview release

https://blogs.msdn.microsoft.com/webdev/2016/10/25/announcing-asp-net-core-1-1-preview-1/

one wprowadzenie nowej odpowiedzi buforowania Middleware. Buforowanie odpowiedzi Middleware

Demo dostępne tutaj. https://github.com/aspnet/ResponseCaching/blob/dev/samples/ResponseCachingSample/Startup.cs

+0

Nigdy nie powiedziałem, że chcę cache po stronie serwera jak outputcache, W zasadzie to robię nie chcę buforować po stronie serwera, chcę buforować dane po stronie klienta. i który to atrybut 'ResponseCache' powinien wykonać – LP13

4

Faktycznie ResponseCache atrybut działa zgodnie z przeznaczeniem.
Różnica polega na tym, że odpowiedź jest zapisywana w pamięci podręcznej, jeśli poruszasz się po stronach witryny (sprawa 1), lub użyj przycisków Wstecz i Dalej (nie podczas odświeżania strony).

Jako przykład przypadku 1, mam następujący:

Jak widać w artykule Response Caching in ASP.Net Core 1.1 się, co następuje stwierdził:

Podczas sesji przeglądarki, przeglądanie wielu stron w witrynie lub korzystając z powrotem i przycisk do przodu do odwiedzenia stron, treści będą serwowane z lokalna pamięć podręczna przeglądarki (jeśli nie wygasła).
Ale kiedy strona zostanie odświeżona przez F5, żądanie zostanie wysłane do serwera, a zawartość strony zostanie odświeżona. Możesz to zweryfikować za pomocą odświeżającej strony kontaktowej za pomocą F5.
Tak więc po naciśnięciu klawisza F5 wartość buforowania odpowiedzi nie ma żadnej roli do wyświetlenia zawartości. Powinieneś zobaczyć odpowiedź 200 dla prośby o kontakt.

Referencje:
[1]. ASP.NET Core Response Caching Sample (using middleware)
[2]. ResponseCache attribute sample
[3]: How to control web page caching, across all browsers?

+0

Metoda akcji Index zwraca View, więc to, co mówisz, może być prawdą (jeszcze nie próbowałem). Moje pytanie dotyczyło jednak metody działania, która zwraca dane w formacie JSON. Tak jak ten, który napisałem w pytaniu. – LP13

+0

Typ zawartości nie ma znaczenia, jeśli używasz przeglądarki i znajdujesz się w określonych sytuacjach, gdy otrzymujesz buforowaną odpowiedź. Jeśli chodzi o Listonosza, jeśli zainstalujesz go jako samodzielną aplikację (pobierając go ze swojej witryny), nie będziesz mieć możliwości buforowania swoich żądań. Ale jeśli zainstalujesz go jako aplikację w Google Chrome, uda Ci się uzyskać odpowiedzi z pamięci podręcznej. Dodam niezbędne informacje do odpowiedzi. – Michael