Briefly, cookies can't be cached by public caches, but since public
documents may make up part of a "stateful dialog", and in
particular the first document in a stateful dialog may be (for
example) a public and cachable home page, servers that wish to
receive the client's cookie on each request, or to issue a new
cookie on requests for a document must set the document up to
require validation on each request. (e.g., by having it be
"pre-expired").

Otherwise, the cache control headers for responses control what a
proxy has to do. If a document is fresh in a cache, a request
containing a cookie does not have to be forwarded to the origin
server, since (by definition) if the document is servable from a
cache, there aren't important side effects at the origin relating
to requests for that document, and so, no changes to the cookie.

One important issue bearing on caching is that for conditional
requests that go through to the origin server, for which the origin
server responds with 304 and also with a set-cookie header, caches
must splice the set-cookie sent by the origin server into their own
response. This is, for example, how it can work to have a home
page that is in a cache, but stale, so that the only traffic to the
origin server is to validate the home page, receiving a 304 and
potentially a new cookie.