Page protected by authentication - should or shouldn't be cached

[rsvoboda]

Page protected by authentication - should or shouldn't be cached (HTTP cache)?

This is followup of discussion on quarkusio/quarkus-quickstarts#1480 where @jedla97 analyzed the root cause of the behavior @gsmet pointed to (quarkusio/quarkus-quickstarts#1480 (comment)).

@michalvavrik commented about some ideas (quarkusio/quarkus-quickstarts#1480 (comment)) and asked to create an issue to have discussion.

CC @sberyozkin @cescoffier

[cescoffier]

What kind of cache are we talking about? Client side cache (browser) or cache annotations.

For the later, except if the cache is able to distinguish users and so handle a different cached value per user, it should not be cached.

For the former, it's tricky. In general, I would say it should not be cached, to avoid potential leak.

[gsmet]

I was talking about HTTP cache. What you do with annotations in your code base is your problem :).

[sberyozkin]

Headers like Cache-Control and Pragma can be used to instruct proxies, but we don't know what kind of deployment ecosystem is in place. If we set it by default, users in intranet can loose the benefit of caching. It is also unclear how much caching actually happens over HTTPS which is what authenticated users will work over with.

I suggest to add a doc section advising users that proxies may have the content cached and if the pages are returned to external authenticated clients, then these cache control headers should be set (it is possible to do it with the configuration or with JAX-RS responses). Additionally, we may advise using MTLS.