Original report by Eric Searcy
Dokuwiki currently provides HTTP/1.0 and HTTP/1.1 protocol cache headers
for _media content. The author of this feature intended  to allow
public caching, with mandatory re-validation to enforce ACLs. However,
there are two issues with it:
(A) HTTP/1.0 public caches may re-serve the response. HTTP/1.0 caches,
given a response with the future Expires header and lack of "Pragma:
no-cache" (if supported by that cache), could therefore bypass ACLs when
re-serving restricted media to additional users (for 1 day by default).
(B) The proxy-revalidate directive only applies to stale content
according to RFC, though there is some misinformation about this in
secondary sources. While proxy-revalidate has same meaning as
must-revalidate except applying only to shared caches, must-revalidate
only says that if cached data is *stale* (past max-age), a stale
response cannot be served---it doesn't affect fresh cached data .
Therefore a public cache, even while respecting proxy-revalidate, can
still serve out restricted media to the wrong user during the time the
cache is fresh (1 day by default).
The attached patch (for "git am") conservatively requires immediate
revalidation (max-age=0/Expires in 1970) and should limit storage to the
browser cache (private). I tested this with Chrome directly hitting a
dokuwiki site, which re-validated and received a "304 Not Modified"
response (did not have to re-download). Testing with a public cache
required the full document to be re-downloaded each time, causing a
minor performance loss. A further enhancement (not coded) would be to
allow public caching for HTTP/1.0 and 1.1 if an ACL check determines
@ALL access. (Note, for HTTP/1.1, setting max-age >0 along with private
directive could still allow an ACL bypass from the same browser after a
user ends their dokuwiki session, hence the choice to require even
private caches to revalidate.)