Dlaczego w odpowiedzi HTTP należy używać zarówno opcji no-cache, jak i no-store?

120

Powiedziano mi, żebym zapobiegał wyciekowi informacji o użytkowniku, tylko odpowiedź „no-cache” nie wystarczy. „brak sklepu” jest również konieczne.

Cache-Control: no-cache, no-store

Po przeczytaniu tej specyfikacji http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html , nadal nie jestem pewien, dlaczego.

Obecnie rozumiem, że jest to tylko dla pośredniego serwera pamięci podręcznej. Nawet jeśli w odpowiedzi pojawi się komunikat „no-cache”, pośredni serwer pamięci podręcznej może nadal zapisywać zawartość w pamięci nieulotnej. Pośredni serwer pamięci podręcznej zdecyduje, czy użyć zapisanej treści dla następnego żądania. Jeśli jednak odpowiedź zawiera informację „no-store”, pośredni serwer pamięci podręcznej nie powinien przechowywać treści. Więc to jest bezpieczniejsze.

Czy jest jakiś inny powód, dla którego potrzebujemy zarówno opcji „no-cache”, jak i „no-store”?

Morgan Cheng
źródło
3
no-cachenie oznacza tego, co myślisz, że to robi. Właściwie oznacza to „proszę ponownie zweryfikować”.
Erwan Legrand

Odpowiedzi:

77

Muszę wyjaśnić, że no-cachenie oznacza to, że nie buforuj . W rzeczywistości oznacza to „ponowne sprawdzenie poprawności z serwerem” przed użyciem jakiejkolwiek odpowiedzi z pamięci podręcznej, którą możesz mieć, na każde żądanie.

must-revalidatez drugiej strony wymaga ponownej walidacji tylko wtedy, gdy zasób zostanie uznany za nieaktualny.

Jeśli serwer twierdzi, że zasób jest nadal ważny, pamięć podręczna może odpowiedzieć swoją reprezentacją, zmniejszając w ten sposób potrzebę ponownego wysłania przez serwer całego zasobu.

no-storejest w rzeczywistości pełną dyrektywą „ nie zapisuj w pamięci podręcznej” i ma na celu zapobieganie przechowywaniu reprezentacji w jakiejkolwiek formie pamięci podręcznej.

Powiem cokolwiek, ale zwróć uwagę na to w specyfikacji HTTP RFC 2616:

Bufory historii MOGĄ przechowywać takie odpowiedzi jako część ich normalnej pracy

Jest to jednak pomijane w nowszej specyfikacji protokołu HTTP RFC 7234 w celu potencjalnej próby no-storewzmocnienia, zobacz:

http://tools.ietf.org/html/rfc7234#section-5.2.1.5

Luke Puplett
źródło
18
Nadal nie odpowiadam na pytanie: dlaczego w odpowiedzi HTTP należy używać zarówno no-cache, jak i no-store? Nie Cache-Control: no-storewystarczy?
Franklin Yu
Czy są różnice między przeglądarkami? Ponieważ ten artykuł z Microsoft docs.microsoft.com/en-us/iis/configuration/system.webServer/ ... nawet nie wspomina no-storei nie opisuje, no-cachejakby w ogóle nie buforował ... Jestem zdezorientowany!
Roel
Odpowiedź Alconji jest właśnie odpowiedzią na to pytanie. Kiedy odpowiedziałem, zrobiłem to tylko po to, aby wyjaśnić bardzo powszechny mikoncepcję. Zagłosuj na drugą odpowiedź!
Luke Puplett
48

W pewnych okolicznościach IE6 będzie nadal buforować pliki, nawet jeśli Cache-Control: no-cacheznajduje się w nagłówkach odpowiedzi.

Stany W3Cno-cache :

Jeśli dyrektywa no-cache nie określa nazwy pola, pamięć podręczna NIE MOŻE używać odpowiedzi w celu spełnienia kolejnego żądania bez pomyślnej ponownej walidacji z serwerem pochodzenia.

W mojej aplikacji, jeśli odwiedziłeś stronę z no-cachenagłówkiem, wylogowałeś się, a następnie wcisnąłeś z powrotem w przeglądarce, IE6 nadal pobierałby stronę z pamięci podręcznej (bez nowego / sprawdzającego żądania do serwera). Dodanie w no-storenagłówku zatrzymało to. Ale jeśli uwierzysz W3C na słowo, tak naprawdę nie ma sposobu, aby kontrolować to zachowanie:

Bufory historii MOGĄ przechowywać takie odpowiedzi jako część ich normalnej pracy.

Ogólne różnice między historią przeglądarki a zwykłym buforowaniem HTTP są opisane w odpowiedniej podsekcji specyfikacji .

Alconja
źródło
7
kiedy wrócisz do przeglądarki, IE6 nie pobiera strony z pamięci podręcznej. Pobiera stronę z bufora historii.
Pacerier,
1
W Chrome 34 (2014) nadal trzeba to ustawić no-store. W przeciwnym razie Chrome pokaże dane z pamięci podręcznej / buforowane, gdy użyjesz przycisku Wstecz.
krakaj
4
-1, ponieważ pierwsze zdanie błędnie sugeruje, że przeglądarka nie może buforować odpowiedzi, która ma no-cachenagłówek. Cytat z W3C bezpośrednio poniżej jasno pokazuje, że tak nie jest; no-cachenagłówek oznacza raczej, że odpowiedź musi zostać ponownie zweryfikowana przed ponownym użyciem do obsługi kolejnych żądań.
Mark Amery
1
Brzmienie specyfikacji zostało poprawione z RFC1616 do aktualnej wersji specyfikacji ( tools.ietf.org/html/rfc7230 rodzina RFC). rodzina, ponieważ jest to 6 specyfikacji RFC. Są przestarzałe 2616.
Arcin B
16

Ze specyfikacji HTTP 1.1 :

brak sklepu :

Cel braku sklepuDyrektywa ma na celu zapobieżenie niezamierzonemu ujawnieniu lub zatrzymaniu wrażliwych informacji (na przykład na taśmach zapasowych). Dyrektywa no-store dotyczy całej wiadomości i MOŻE zostać wysłana w odpowiedzi lub w żądaniu. W przypadku wysłania żądania pamięć podręczna NIE MOŻE przechowywać żadnej części ani tego żądania, ani odpowiedzi na nie. W przypadku wysłania w odpowiedzi pamięć podręczna NIE MOŻE przechowywać żadnej części ani tej odpowiedzi, ani żądania, które ją wywołało. Ta dyrektywa dotyczy zarówno niewspółdzielonych, jak i współużytkowanych pamięci podręcznych. „NIE WOLNO przechowywać” w tym kontekście oznacza, że ​​pamięć podręczna NIE MOŻE celowo przechowywać informacji w pamięci nieulotnej i MUSI dołożyć wszelkich starań, aby usunąć informacje z pamięci ulotnej tak szybko, jak to możliwe po ich przesłaniu. Nawet jeśli ta dyrektywa jest powiązana z odpowiedzią, użytkownicy mogą jawnie przechowywać taką odpowiedź poza systemem pamięci podręcznej (np. za pomocą okna dialogowego „Zapisz jako”). Bufory historii MOGĄ przechowywać takie odpowiedzi jako część ich normalnej pracy. Celem tej dyrektywy jest spełnienie określonych wymagań określonych użytkowników i autorów usług, którzy są zaniepokojeni przypadkowym ujawnieniem informacji poprzez nieoczekiwany dostęp do struktur danych pamięci podręcznej. Chociaż stosowanie tej dyrektywy może w niektórych przypadkach poprawić prywatność, ostrzegamy, że NIE jest to w żaden sposób niezawodny ani wystarczający mechanizm zapewniający prywatność. W szczególności złośliwe lub zainfekowane pamięci podręczne mogą nie rozpoznawać tej dyrektywy lub jej przestrzegać, a sieci komunikacyjne mogą być narażone na podsłuchiwanie. Bufory historii MOGĄ przechowywać takie odpowiedzi jako część ich normalnej pracy. Celem tej dyrektywy jest spełnienie określonych wymagań określonych użytkowników i autorów usług, którzy są zaniepokojeni przypadkowym ujawnieniem informacji poprzez nieoczekiwany dostęp do struktur danych pamięci podręcznej. Chociaż stosowanie tej dyrektywy może w niektórych przypadkach poprawić prywatność, ostrzegamy, że NIE jest to w żaden sposób niezawodny ani wystarczający mechanizm zapewniający prywatność. W szczególności złośliwe lub zainfekowane pamięci podręczne mogą nie rozpoznawać tej dyrektywy lub jej przestrzegać, a sieci komunikacyjne mogą być narażone na podsłuchiwanie. Bufory historii MOGĄ przechowywać takie odpowiedzi jako część ich normalnej pracy. Celem tej dyrektywy jest spełnienie określonych wymagań określonych użytkowników i autorów usług, którzy są zaniepokojeni przypadkowym ujawnieniem informacji poprzez nieoczekiwany dostęp do struktur danych pamięci podręcznej. Chociaż stosowanie tej dyrektywy może w niektórych przypadkach poprawić prywatność, ostrzegamy, że NIE jest to w żaden sposób niezawodny ani wystarczający mechanizm zapewniający prywatność. W szczególności złośliwe lub zainfekowane pamięci podręczne mogą nie rozpoznawać tej dyrektywy lub jej przestrzegać, a sieci komunikacyjne mogą być narażone na podsłuchiwanie. Chociaż stosowanie tej dyrektywy może w niektórych przypadkach poprawić prywatność, ostrzegamy, że NIE jest to w żaden sposób niezawodny ani wystarczający mechanizm zapewniający prywatność. W szczególności złośliwe lub zainfekowane pamięci podręczne mogą nie rozpoznawać tej dyrektywy lub jej przestrzegać, a sieci komunikacyjne mogą być narażone na podsłuchiwanie. Chociaż stosowanie tej dyrektywy może w niektórych przypadkach poprawić prywatność, ostrzegamy, że NIE jest to w żaden sposób niezawodny ani wystarczający mechanizm zapewniający prywatność. W szczególności złośliwe lub zainfekowane pamięci podręczne mogą nie rozpoznawać tej dyrektywy lub jej przestrzegać, a sieci komunikacyjne mogą być narażone na podsłuchiwanie.

ukośnik odwrotny17
źródło
1
Jeśli nie buforujesz już żądania, czy nie uniemożliwiłoby to już przechowywania odpowiedzi na nieulotnym nośniku?
Lèse majesté
4
@ Lèsemajesté Najczęściej nie. no-cachei max-age=0powiedz, że przedmiot ma być uważany za nieaktualny. Oznacza to, że przed przekazaniem należy go ponownie zweryfikować. Oznacza to, że pamięć podręczna może przechowywać plik, a następnie wykonać warunkowe żądanie, na które serwer mógłby odpowiedzieć 304 NOT MODIFIED. Jest to oczywiście ogromna zaleta, ponieważ treść odpowiedzi nie musi być generowana ani wysyłana. Tak więc, aby skorzystać z tej wielu (większości?) Pamięci podręcznych, będą przechowywane no-cacheodpowiedzi.
Kevin Cox
14

Jeśli chcesz zapobiec wszelkiemu buforowaniu (np. Wymusić przeładowanie podczas korzystania z przycisku Wstecz), potrzebujesz:

  • no-cache dla IE

  • no-store dla przeglądarki Firefox

Moje informacje na ten temat są tutaj:

http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/

HttpWatchSupport
źródło
6
Dlaczego żaden sklep nie byłby wystarczający dla Internet Explorera? Twój post na blogu nie wyjaśnia.
Simon Lieschke
1
O której wersji IE mówisz?
Pacerier,
1
@Pacerier, Prawdopodobnie niezależnie od wersji IE była najnowsza w momencie, gdy pisał komentarz. Według Wikipedii był to IE7. W przypadku FF wygląda to na 3. Niewiele osób nadal też używa.
trysis
11

no-storenie powinno być konieczne w normalnych sytuacjach i może zaszkodzić zarówno szybkości, jak i użyteczności. Jest przeznaczony do użytku w przypadku, gdy odpowiedź HTTP zawiera informacje tak wrażliwe, że w ogóle nie powinna być zapisywana w pamięci podręcznej dysku, niezależnie od negatywnych skutków, jakie stwarza to dla użytkownika.

Jak to działa:

  • Zwykle, nawet jeśli agent użytkownika, taki jak przeglądarka, ustali, że odpowiedź nie powinna być buforowana, może nadal przechowywać ją w pamięci podręcznej dysku z powodów wewnętrznych dla agenta użytkownika. Ta wersja może być wykorzystywana do takich funkcji, jak „wyświetl źródło”, „wstecz”, „informacje o stronie” itd., Gdzie użytkownik nie musi koniecznie ponownie zażądać strony, ale przeglądarka nie uważa tego za nowy widok strony i miałoby sens serwowanie tej samej wersji, którą aktualnie przegląda użytkownik.

  • Użycie no-storeuniemożliwi przechowywanie tej odpowiedzi, ale może to wpłynąć na możliwość podania przez przeglądarkę „źródła wyświetlania”, „wstecz”, „informacji o stronie” itd. Bez wysyłania nowego, oddzielnego żądania do serwera, co jest niepożądane. Innymi słowy, użytkownik może spróbować wyświetlić źródło, a jeśli przeglądarka nie zachowała go w pamięci, albo zostanie poinformowany, że nie jest to możliwe, albo spowoduje to nowe żądanie do serwera. Dlatego no-storepowinno być używane tylko wtedy, gdy utrudniane przez użytkownika korzystanie z tych funkcji nie działa prawidłowo lub szybko jest równoważone przez znaczenie zapewnienia, że ​​zawartość nie jest przechowywana w pamięci podręcznej.

Obecnie rozumiem, że jest to tylko dla pośredniego serwera pamięci podręcznej. Nawet jeśli w odpowiedzi pojawi się komunikat „no-cache”, pośredni serwer pamięci podręcznej może nadal zapisywać zawartość w pamięci nieulotnej.

To jest niepoprawne. Serwery pośredniczące z pamięcią podręczną zgodne z protokołem HTTP 1.1 będą przestrzegać instrukcji no-cachei must-revalidate, zapewniając, że zawartość nie jest buforowana. Skorzystanie z tych instrukcji zapewni, że odpowiedź nie będzie buforowana przez żadną pośrednią pamięć podręczną, a wszystkie kolejne żądania będą wysyłane z powrotem do serwera pochodzenia.

Jeśli pośredni serwer pamięci podręcznej nie obsługuje protokołu HTTP 1.1, będziesz musiał użyć Pragma: no-cachei mieć nadzieję na najlepsze. Zauważ, że jeśli nie obsługuje HTTP 1.1, no-storeto i tak nie ma znaczenia.

thomasrutter
źródło
3
Czy coś źle rozumiem, ponieważ mnot.net/cache_docs/#CACHE-CONTROL Ci zaprzecza. Mówi, że no-cachezachowuje sztywną świeżość bez poświęcania wszystkich zalet buforowania, co oznacza, że ​​pamięć podręczna jest przechowywana i używana ponownie, jeśli serwer odpowie komunikatem 304 Not Modified.
Pacerier,
-1: no-cache nie oznacza, że ​​zawartość nie może być buforowana. W 14.9.1 Co jest buforowalne specyfikacja mówi: „Jeśli dyrektywa no-cache nie określa nazwy pola, pamięć podręczna NIE MOŻE używać odpowiedzi do spełnienia kolejnego żądania bez pomyślnej ponownej walidacji z serwerem pochodzenia”. ( w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 ) . Jak wyjaśnia Chris Shiflett, „nie uniemożliwia systemowi buforowania przechowywania kopii w pamięci podręcznej. Po prostu wymaga, aby system buforujący ponownie zweryfikował swoją pamięć podręczną przed do odesłania go do klienta ”. (Podręcznik dewelopera HTTP, str. 91)
james.garriss,
Nie wydaje mi się, żeby to, co napisałem w tej odpowiedzi, zgadza się z żadnym z tych dwóch komentarzy - po prostu nie mówiłem o tym, jak przeglądarki rewalidują (np. Używając If-Modified-Since / If-None-Match), ponieważ nie widziałem tego jako istotnych. Nie próbowałem nawet wyjaśnić, do czego służy brak pamięci podręcznej, więc mam trudności ze zrozumieniem, w jaki sposób komentarz @ james.garriss odnosi się do mojej odpowiedzi.
thomasrutter
7

Jeśli system buforowania poprawnie implementuje brak przechowywania, nie potrzebujesz żadnej pamięci podręcznej. Ale nie wszyscy. Ponadto niektóre przeglądarki implementują brak pamięci podręcznej, tak jakby to był brak przechowywania. Tak więc, chociaż nie jest to ściśle wymagane, prawdopodobnie najbezpieczniej jest uwzględnić oba.

james.garriss
źródło
Ale nie wszyscy. „Potrzebujemy konkretnego przykładu, aby przekonać mojego kolegę.
Franklin Yu
Ten komentarz został złożony 6 lat temu. Będziesz musiał zbadać obecne zachowanie serwerów buforujących, aby zobaczyć, co robią.
james.garriss
6

Zwróć uwagę, że Internet Explorer od wersji 5 do 8 zgłosi błąd podczas próby pobrania pliku obsługiwanego przez https i serwer wysyłający Cache-Control: no-cachelub Pragma: no-cachenagłówki.

Zobacz http://support.microsoft.com/kb/812935/en-us

Użycie Cache-Control: no-storei Pragma: privatewydaje się być najbliższą rzeczą, która nadal działa.

basim
źródło
2
Jak zasugerowano w powiązanej odpowiedzi SO , możesz ustawić Cache-Control: no-store, no-cache, must-revalidatedokładną kolejność, aby to zadziałało. Jednak to nie zadziałało w naszym scenariuszu, ale to, co zasugerował @bassim powyżej, zadziałało. Dzięki!
Eirik H
6

W przypadku Chrome, no-cache jest używany do ponownego załadowania strony przy ponownej wizycie, ale nadal buforuje ją, jeśli wrócisz do historii (przycisk Wstecz). Aby ponownie załadować stronę w celu przywrócenia historii, użyj opcji no-store. IE wymaga ponownej walidacji, aby działać w każdej sytuacji.

Więc tylko po to, aby uniknąć wszystkich błędów i błędnych interpretacji, których zawsze używam

Cache-Control: no-store, no-cache, must-revalidate

jeśli chcę się upewnić, że się ponownie załaduje.

woens
źródło
2

Pierwotnie korzystaliśmy z no-cache wiele lat temu i napotkaliśmy pewne problemy z nieaktualnymi treściami w niektórych przeglądarkach ... Nie pamiętam niestety szczegółów.

Od tego czasu zdecydowaliśmy się TYLKO na korzystanie z braku sklepu. Od tamtej pory nigdy nie oglądałem się za siebie ani nie miałem ani jednego problemu z nieaktualnymi treściami w jakiejkolwiek przeglądarce lub u pośredników.

Ta przestrzeń jest z pewnością zdominowana przez rzeczywistość implementacji w porównaniu z tym, co zostało napisane w różnych dokumentach RFC. W szczególności wiele serwerów proxy ma tendencję do myślenia, że ​​lepiej „poprawiają wydajność”, zastępując politykę, której powinni przestrzegać, własną.

Einstein
źródło
Uważam, że to Firefox preferował no-store.
bvdb,
-1

OWASP omawia to:

Jaka jest różnica między dyrektywami Cache-Control: no-cache i no-store?

Dyrektywa no-cache w odpowiedzi wskazuje, że odpowiedź nie może służyć do obsługi kolejnego żądania, tj. Pamięć podręczna nie może wyświetlać odpowiedzi, która ma tę dyrektywę ustawioną w nagłówku, ale musi pozwolić serwerowi obsłużyć żądanie. Dyrektywa no-cache może zawierać niektóre nazwy pól; w takim przypadku odpowiedź może zostać wyświetlona z pamięci podręcznej, z wyjątkiem określonych nazw pól, które mają być obsługiwane z serwera. Dyrektywa no-store dotyczy całej wiadomości i wskazuje, że pamięć podręczna nie może przechowywać żadnej części odpowiedzi ani żadnego żądania, które o to poprosiło.

Czy jestem całkowicie bezpieczny dzięki tym dyrektywom?

Nie. Ale generalnie używaj zarówno Cache-Control: no-cache, no-store i Pragma: no-cache, oprócz Expires: 0 (lub wystarczająco datowanej daty GMT, takiej jak epoka UNIX). Typy zawartości inne niż HTML, takie jak PDF, dokumenty Word, arkusze kalkulacyjne programu Excel itp., Często są buforowane, nawet jeśli ustawione są powyższe dyrektywy kontroli pamięci podręcznej (chociaż zależy to od wersji i dodatkowego użycia funkcji must-revalidate, pre-check = 0, post-check = 0, max-age = 0 i s-maxage = 0 w praktyce czasami mogą skutkować przynajmniej usunięciem pliku po zamknięciu przeglądarki w niektórych przypadkach z powodu dziwactw przeglądarki i implementacji HTTP). Ponadto funkcja „Autouzupełnianie” umożliwia przeglądarce buforowanie wszystkiego, co użytkownik wpisze w polu wejściowym formularza. Aby to sprawdzić, tag formularza lub poszczególne tagi wejściowe powinny zawierać atrybut „Autocomplete =„ Off ””. Jednak,

Źródło tutaj .

Jan Żankowski
źródło
To jest niepoprawne. no-cachemówi, że nie możesz go używać bez weryfikacji z serwerem. Jeśli kopia z pamięci podręcznej jest nadal dobra, serwer odpowie numerem 304, a następnie użyjesz kopii z pamięci podręcznej. Oszczędza potencjalnie duże pobieranie sieciowe. no-storez drugiej strony mówi, że nie możesz w ogóle buforować danych.
Gargoyle