Prywatne vs publiczne w kontroli pamięci podręcznej

127

Czy możesz opisać przykład wskazujący różnicę między publiczną i prywatną kontrolą pamięci podręcznej w aplikacjach asp.net hostowanych w usługach IIS.

W MSDN przeczytałem, że różnica jest następująca:

Public: Ustawia Cache-Control: public, aby określić, że odpowiedź może być buforowana przez klientów i współużytkowane (proxy) pamięci podręczne.

Prywatne: wartość domyślna. Ustawia kontrolę pamięci podręcznej: prywatna, aby określić, że odpowiedź może być buforowana tylko na kliencie, a nie przez współużytkowane (serwer proxy) pamięci podręczne.

Nie jestem pewien, czy w pełni zrozumiałem zalety i wady każdego wyboru. Byłby świetny przykład, kiedy go używać, a kiedy nie.

Na przykład co powinienem zrobić, jeśli mam dwa serwery internetowe obsługujące tę samą aplikację? Czy jest na co uważać, jeśli wybiorę opcję Prywatną lub Publiczną?

— ppolyzos
źródło

237

Jedyna różnica polega na tym, że w przypadku opcji Private nie zezwalasz serwerom proxy na buforowanie danych, które przez nie przechodzą. Ostatecznie wszystko sprowadza się do danych zawartych w przesyłanych stronach / plikach.

Na przykład Twój dostawca usług internetowych może mieć niewidoczne proxy między Tobą a Internetem, czyli buforowanie stron internetowych w celu zmniejszenia wymaganej przepustowości i obniżenia kosztów. Używając cache-control: private, określasz, że nie powinno buforować strony (ale zezwalasz na to użytkownikowi końcowemu). Jeśli używasz cache-control: public, mówisz, że każdy może buforować stronę, więc serwer proxy zachowa kopię.

Z reguły, jeśli to coś dla każdego może uzyskać dostęp (na przykład logo na tej stronie) kontrola pamięci podręcznej: public może być lepszy, ponieważ im więcej osób je buforuje, tym mniej przepustowości będziesz potrzebować. Jeśli jest to coś, co jest związane z podłączonym użytkownikiem (na przykład kod HTML na tej stronie zawiera moją nazwę użytkownika, więc nie będzie przydatny dla nikogo innego) kontrola pamięci podręcznej: prywatna będzie lepsza, ponieważ serwery proxy będą buforować dane to nie będzie wymagane przez innych użytkowników, a także mogą przechowywać dane, których nie chcesz przechowywać na serwerach, którym nie ufasz.

I oczywiście wszystko, co nie jest publiczne, powinno mieć prywatną pamięć podręczną. W przeciwnym razie dane mogłyby być przechowywane na pośrednim serwerze proxy, gdyby ktoś miał do nich dostęp.

— salgiza
źródło

Jedyną różnicą jest to, że w przypadku Private nie pozwalasz serwerom proxy na buforowanie ... Zgaduję, że to była literówka. +1 w odpowiedzi oprócz tego. Warto dodać, że prywatny nie zapewnia żadnego stopnia bezpieczeństwa, nadal jest widoczny dla agentów pośrodku. Oznacza to po prostu, że żaden „uczciwy” agent nie przekaże go komuś innemu zamiast świeżo wygenerowanej odpowiedzi.

— Jon Hanna,

Naprawiony! To zabawne, ponieważ przeczytałem to kilka razy przed wysłaniem, ale myślę, że wiedziałem, że „nie” musi tam być, więc mój umysł po prostu dodał to: D. I tak, +1 do Twojego komentarza, ponieważ należy zauważyć, że chociaż zalecane w przypadku danych dotyczących użytkowników, prywatność nie zastąpi prawdziwego bezpieczeństwa (SSL).

— salgiza,

Tak łatwo jest albo napisać „nie”, kiedy nie powinieneś, albo pominąć, kiedy powinieneś. Wiem, że wiele moich własnych zmian (w różnych polach) naprawia tę samą literówkę.

— Jon Hanna

Jeśli więc nic nie określimy, czy domyślne zachowanie jest „publiczne” czy „prywatne”?

— Pacerier,

@ Kochanie, ale może być kilku klientów korzystających z tego samego serwera proxy. Jeśli wszystko jest w porządku, wyślij wszystkim klientom tę samą odpowiedź, wtedy można buforować na poziomie serwera proxy, w przeciwnym razie może być w porządku buforowanie na kliencie (wciąż są przypadki, w których nawet to zły pomysł), ale nie na serwerze proxy.

— Jon Hanna,