By default Joomla response has only the Expires header in the past
The header Cache-Control: max-age=x is not set (and i mean the max-age part of this header)

And when Cache-Control: max-age=x is not set
then default behaviour of browsers is to respect the expires header

So whatever is happening it is not because of Joomla default response
Did you check if header Cache-Control: max-age=x is present ?
maybe some extension is setting it

--> without deleting the cache of the browser, the update in the css will not load -- browser seem to hold the html of the website in their cache for an unspecified period of time.

because of the above i assume that the problem is not a proxy
also if you open the browser tools and go to network TAB and you reload the page, you will see which exact requests the browser is caching

Hi Georgios,

Thank you very much for following up on this.

Let me response to your reply in revise order.

-- Yes, you are right, my testing an observation shows that the problem occurs at browser level: ie. the browser loads the current html only when I clean the browser cache. Until cleaning the cache, the browser may load only the cached version of the html.

The Cache-Control: max-age=x: this is not present in the html http response of either a clean J3.8.6 installation or in my J websites.

-- "And when Cache-Control: max-age=x is not set then default behaviour of browsers is to respect the expires header": my extensive testing, and some initial research contradicts this. Both Google and Firefox appear to suggest that the way to control http cache is the Cache-Control: max-age=x .

Google Http Caching document
Firefox Http caching document

Firefox, in the given document, specifically says the following:
"Pragma is a HTTP/1.0 header, it is not specified for HTTP responses and is therefore not a reliable replacement for the general HTTP/1.1 Cache-Control header, although it does behave the same as Cache-Control: no-cache, if the Cache-Control header field is omitted in a request. Use Pragma only for backwards compatibility with HTTP/1.0 clients."

-- By default Joomla response has only the Expires header in the past: yes -- more accurately, the J default http cache control includes the Expires: Wed, 17 Aug 2005 00:00:00 GMT and the Pragma: no-cache directives.
My main issue is that it appears, there is no obvious way to override these directives, leaving the J website without the recommended Cache-Control header -- and the ability to control how/when the visitors of the website can view its most current version.

Regarding the issue, you may also refer to WP, whereas the default html http response doesn't include the earlier directives, but there is a wildly used WP plugin that enables you add and customize your html http response in the appropriate format -- the Cache-Control: max-age=x .

PS.: I just noticed that there in the header of the Joomla.org website, the ominous Expires: Wed, 17 Aug 2005 00:00:00 GMT and the Pragma: no-cache directives are missing.
This seems to be the good direction, but one should have the ability to add the recommended the Cache-Control: max-age=x html http header.

PS.: I just noticed that there in the header of the Joomla.org website, the ominous Expires: Wed, 17 Aug 2005 00:00:00 GMT and the Pragma: no-cache directives are missing.

Look again ;)

My main issue is that it appears, there is no obvious way to override these directives, leaving the J website without the recommended Cache-Control header -- and the ability to control how/when the visitors of the website can view its most current version.

There are several extensions available eg
https://extensions.joomla.org/extension/cachecontrol/
https://extensions.joomla.org/extension/expires-headers/

Hi Brian,

Thank you for looking into this.

-- The Joomla.org website: you are right -- by accident, I was testing http://www.joomla.org instead of https:/www.joomla.org in the websniffer.cc -- so, the ominous html http rsponse is there while the recommended cache-control response is missing.

-- Cache control extension: this seems to be concerned with server cache
-- Expires headers extension: based on the description, this extension adds expiry headers to the htaccess file. Unfortunately, as per my testing, htaccess file cannot and won't override the default J header.
I haven't tested the given commercial plugin. I will reach out to the developer to double-check if his plugin is adding expiry headers via the htaccess file or some other way.
The html http response header of the developer's website is identical to the default J header -- I suspect that this extension cannot be used for addressing the given issue.

BTW, not having the ability to get rid of the Expires: Wed, 17 Aug 2005 00:00:00 GMT response appears to be a security risk as well. The best practice is to make it possible to hide the type of the given CMS, however, in this case, the header makes it obvious that it is generated by Joomla.

BTW, not having the ability to get rid of the Expires: Wed, 17 Aug 2005 00:00:00 GMT response appears to be a security risk as well. The best practice is to make it possible to hide the type of the given CMS, however, in this case, the header makes it obvious that it is generated by Joomla.

Absolutely not!!! That is security by obscurity which is never a best practice

Brian, thank you for your comment.

To me, it looks, the trend is that the application designers try to obscure the signature of their application as much as possible. Anyhow, I am by no means a security expert, and at this point, it is more important that the it seems, there is no solution available for overriding the out-of-date J default cache control directives.

The developer of the Expires Headers extension got back to me, and in his response, he indicated that his extension works through the htaccess file, which, unfortunately, doesn't solve the issue.

This seems to be a critical issue, which was very smoothly addressed by WP a while ago.

@atomhbc

I have made a PR you can see the reference above, can you test it ?
#20016

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/20008

closed as having Pull Request #20016

Hi Georgios,

Yes, thank you for arranging this.
I just tested the suggested PR.

In the /public_html/libraries/src/Application/WebApplication.php file, I
replaced the // Expires in the past .... ('Expires', 2005 Aug 17... )
string to the following.

             // Private.

$this->setHeader('Cache-Control', 'private', true);

// Expires in the past.
$this->setHeader('Cache-Control', 'max-age=10', true);

Result:

The http response header now includes the following line:
Cache-Control: max-age=10, no-store, no-cache, must-revalidate,
post-check=0, pre-check=0
The Cache-Control: private line is missing however.

Also, interestingly, first, I tested the solution without changing my
htaccess file. Since the htaccess file included the following:

html

ExpiresByType text/html "access plus 1 hour", the following http Cache
Control response was generated:
Cache-Control

max-age=10, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
max-age=3600

Summary:

• replacing the Expires 2005 Aug 17 with Cache-Control: max-age=x does
  seem to work
• The Cache-Control: private formula is not accepted
• when the Expires 2005 Aug 17 is not present, on my server, the
  htaccess file does have the ability to modify the html http response header

Comment:

1. For the long run, how about considering a solution whereas there
   would be no set values for the Cache-Control?
   In WP, by default, there is no cache-value set. Then, there is a free
   plug-in, that can be used for setting the cache-control values at a very
   granular level.
   See screenshot attached.
2. Since the Expires header is updated to the more appropriate
   Cache-Control:
   max-age=x form for the non-page cache scenario, how about updating it for
   the page-cache scenario as well?

Regards,
Tom

Tom Hollai
Phone: +1-604-710-0661

On Wed, Mar 28, 2018 at 9:46 PM, Georgios Papadakis <
notifications@github.com> wrote:

@atomhbc https://github.com/atomhbc

I have made a PR you can see the reference above, can you test it ?
#20016 #20016

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#20008 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AkB11ezS4fFP-XaShCltwJrhnamU0njXks5tjGc7gaJpZM4S90AJ
.

The Cache-Control: private formula is not accepted

This is because the $this->setHeader('Cache-Control', 'max-age=10', true); line is overwriting your Cache-Control header. setHeader() has the same signature as PHP's native header(), and the third parameter is a boolean flag setting whether the header's value should be replaced if already set.

Beyond that, the code needs to continues to support both HTTP/1.0 and HTTP/1.1 responses (no idea if the proposed changes are affecting that but just need to say it to ensure we don't break something).

It is as @mbabker said

Further more to set both private and max-age you should use 1 command not 2
$this->setHeader('Cache-Control', 'private, max-age=0 ...

also the default value for Cache-Control for joomla here
https://github.com/joomla/joomla-cms/pull/20016/files#diff-d9a3e107f03ee47d8c7fea2cc9affa72R508

is using $replace false,
which means that you can use a 3rd party plugin , or custom code to control caching

https://github.com/ggppdk/joomla-cms/blob/bf8dd39ad57ca3af3316663242c2bdfc55ec9eba/libraries/src/Application/WebApplication.php#L698-L705

I think PR #20016 is enough,

that is if it does not cause any "issues" to existing websites (which i believe it does not)
at worst it should enable proper caching behaviour, which is by default OFF but allow overriding via 3rd party plugin or code in current view

and max-age is quoting
"Contrary to Expires, this directive is relative to the time of the request."

thus max-age=0 means expire immediately

@ggppdk --
"is using $replace false,
which means that you can use a 3rd party plugin , or custom code to control caching"

One advantage of not defining Cache-Control in the default J html http response is the following. While there is no set default html response, the html (and all the other file type) response headers can be easily controlled by the htaccess file. However, if the html http default response is set, it appears, currently, for the J community, there is no way to control the html caching.
For example, it seems, the most commonly used html caching setting is max-age=10. This ensures that updates are promptly loaded in browsers, while giving a layer of protection to the server. Many webmasters would however consider having max-age=300 or even max-age=3600 for their website.

Anyhow, you probably have a better overview on the pros and cons of having default html http response. I just wanted to draw attention to the earlier con, in case it hasn't been considered