HTTP Proxy Caching for URLs with Query Strings

A query string does not make a response uncacheable under modern HTTP rules. A public resource such as /catalog?page=2 can state its intended freshness directly:

Cache-Control: public, max-age=60

That is an illustrative policy for public content. The response still has to satisfy the other cacheability requirements. Personalized results should not acquire shared caching merely because a proxy operator wants a better hit rate.

The query remains part of the target URI used in the cache key. Page 2 and page 3 are different requests. Stripping the query to make their URLs look alike can serve one result for the other; it does not make the results equivalent.

HTTP's older restriction on heuristic freshness for query URLs was removed after it proved poorly implemented. Explicit freshness avoids relying on a cache's guess, while local proxy rules can still exclude particular URLs.

Ordinary HTTPS CONNECT traffic leaves the resource and its cache policy inside TLS. The tunneling forward proxy does not gain an object cache for those pages simply because the URL uses a query.