Moodle in English: Moodle and Cache-Control directive sometimes make reverse proxies work hard

Moodle and Cache-Control directive sometimes make reverse proxies work hard

by Matteo Scaramuccia - Friday, November 7, 2014, 5:53 AM

Hi Community,
I'd like to get your attention on MDL-48023. There, we're discussing about improving performances by letting a reverse proxy doing its own job, given a clear use case.
Indeed, there are some hard coded settings to satisfy the security over performance statement which affect performances, precisely they prevent shared proxies to cache:

some theme related files, including those from 3rd party themes served via \theme_config::setting_file_serve();
user profile images.

A proposal has been already provided by hard - again - coding the possibility to expose the items above to shared proxies (including reverse proxies).

We want to have your feedback about:

your experience with shared proxies, especially when Moodle runs behind a reverse proxy;
your concerns about disclosing image profiles to shared proxies as per the current Moodle configuration related settings i.e. only if both forcelogin and forceloginforprofileimage are not checked;

Besides we'd like to have thoughts from people coding both plugins and themes, since there could be room to improve the current way of serving files by exposing an option to decide when using the private directive in Cache-Control, giving the Developer the full control - including the ownership! - to manage this cache response directive that will be by default secure and conservative as per now.

TIA,
Matteo

Re: Moodle and Cache-Control directive sometimes make reverse proxies work hard

by Emanuelis Norbutas - Friday, November 7, 2014, 7:53 AM

Hello,

1. Moodle is not designed to run without a reverse proxy at all.

Default page after login (with zero logged in other users in the list ) has 36 static components, but all of them are served via php process. Even more static components (avatars/icons) when more users logged in ("Online users" block).

This is a terrible performance design unless used with caching reverse proxy.

All theme files must be "Cache-Control: public" (or at least cannot imagine any reason for a theme file being private).

2. forcelogin and forceloginforprofileimage options _must_ work independently.

forcelogin _must_ hide user profile details from guests, but not disable avatars/icons caching in reverse proxies. Cache-Control header still _must_ be "public".

forceloginforprofileimage _must_ hide avatars/icons from guests and set Cache-Control to "private".

This is the only optimal solution in "privacy vs performance" without adding any aditional options.

* Public sites will show everything as public (and avatars/icons cacheable).

* Paranoid sites will hide profiles AND avatars/icons from guests.

* Optimal closed sites will hide profiles from guests but allow avatars/icons caching in proxies to perform better and save resourses (Think green!).

* Dumb sites will show profiles publicly but disallow avatars/icons caching.

And I agree that Cache-Control header should be controlled by plugin/theme.

Average of ratings: -

Re: Moodle and Cache-Control directive sometimes make reverse proxies work hard

by Matteo Scaramuccia - Saturday, November 8, 2014, 2:15 PM

Any thought?
'Till now, feedback is coming from the people involved in MDL-48023 which is fine: it gives you the clear picture of the current design and where we'd like to go for what reasons.

Please, remember: silence means consent .

TIA,
Matteo

Average of ratings: -

Re: Moodle and Cache-Control directive sometimes make reverse proxies work hard

by Dan Poltawski - Wednesday, November 12, 2014, 5:44 PM

Average of ratings: -

Re: Moodle and Cache-Control directive sometimes make reverse proxies work hard

by Matteo Scaramuccia - Sunday, November 16, 2014, 5:23 PM

TNX Dan for your feedback.
I've just filed MDL-48245 too.

Average of ratings: -

Hardware and performance

Moodle and Cache-Control directive sometimes make reverse proxies work hard