Buforowanie proxy HTTP dla adresów URL z ciągami zapytań

Ciąg zapytania nie czyni odpowiedzi niebuforowalną według współczesnych reguł HTTP. Zasób publiczny, taki jak /catalog?page=2, może wprost zadeklarować zamierzoną świeżość:

Cache-Control: public, max-age=60

To przykładowa polityka dla treści publicznych. Odpowiedź nadal musi spełniać pozostałe wymagania buforowalności. Wyniki spersonalizowane nie powinny uzyskiwać współdzielonej pamięci podręcznej tylko dlatego, że operator proxy chce lepszego współczynnika trafień.

Zapytanie pozostaje częścią docelowego URI używanego w kluczu pamięci podręcznej. Strona 2 i strona 3 to różne żądania. Usunięcie zapytania, aby ich adresy URL wyglądały tak samo, może obsłużyć jeden wynik zamiast drugiego; nie czyni to wyników równoważnymi.

Starsze ograniczenie HTTP dotyczące heurystycznej świeżości adresów URL z zapytaniem zostało usunięte po stwierdzeniu, że było źle zaimplementowane. Jawna świeżość pozwala uniknąć polegania na domysłach pamięci podręcznej, a lokalne reguły proxy nadal mogą wykluczać określone adresy URL.

Zwykły ruch HTTPS CONNECT pozostawia zasób i jego politykę buforowania wewnątrz TLS. Tunelujące proxy przekazujące nie uzyskuje pamięci podręcznej obiektów dla tych stron tylko dlatego, że adres URL używa zapytania.