You should use the
private directive. Note that content will remain available within the user's browser, even if the
Expires header is set as this header does not necessarily force the browser to purge it after the date and time set so it does not meet your session time-out requirement. However, if this risk is acceptable then it may be suitable.
You could make sure the
Last-Modified header is set so the browser knows whether to update content.
Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache, such as a proxy server.
From RFC2616 section 14.9.1
Taken from this post.
no-store is not suitable if you definitely want caching in the browser (em me), also from RFC:
The purpose of the no-store directive is to prevent the inadvertent
release or retention of sensitive information (for example, on backup
tapes). The no-store directive applies to the entire message, and MAY
be sent either in a response or in a request. If sent in a request, a
cache MUST NOT store any part of either this request or any response
to it. If sent in a response, a cache MUST NOT store any part of
either this response or the request that elicited it. This directive
applies to both non- shared and shared caches. "MUST NOT store" in
this context means that the cache MUST NOT intentionally store the
information in non-volatile storage, and MUST make a best-effort
attempt to remove the information from volatile storage as promptly as
possible after forwarding it.
However, it does also say
History buffers MAY store such responses as part of their normal
so navigating backwards to content will still be possible from the cache, assuming it has not yet been removed for memory management purposes.
Also some browsers may still ask for the whole file again, which is another reason that this may not be suitable:
we also do not send an if-modified-since request when validating
'no-store' content in the cache because we are not supposed to have a
copy of it from a HTTP point-of-view.