I'm working on a Kerberos style cookie-based authentication mechanism for static files for the Nginx web-server (the cookie contains an encrypted string which much match with a sub-string in the URL, the sub-string is specified by a regular expression). The system does not require MITM security, and if it will we will probably just enable HTTPS (which is never cached). In order to choose a caching policy I need to know what guarantees proxies provide.
The authentication mechanisms arbitrates for static content. The static content in question may be regenerated at any time. "no-store" simply turns cacheing off, and I am really tempted to perhaps just avoid the headache of cacheing entirely by going down this route. However perhaps I should go for "private max-age=30 must-revalidate", which should at least allow the browser to cache the content for a short window (30 seconds).
However "no-cache" looks nice on paper according to the definition provided on this page. "no-cache" states that if a shared-proxy is present, the proxy must revalidate the content on each request before it serves it. In order for this to make sense I have to recheck the cookies validity in the server. So I would rely on the proxy server to make a HTTP "HEAD" call with the "if-modified-since" header set and with the cookie supplied by the user and forwarded by the proxy -- additionally, the shared-proxy must respect and forward a 303 request (which occurs when access is denied).
I want advice -- from people who know the ins and outs of the majority of crappy proxies that are in wild -- about which method I should choose.