I can reproduce this on any WMF wiki (including *.beta.wmflabs.org, both logged in and logged out), but not on my private test wiki or on other public wikis like http://www.explainxkcd.com, where Cache-Control is set as requested by the parameters (or as the set default). So I guess it's Varnish that replaces the Cache-Control with "Cache-Control:private, s-maxage=0, max-age=0, must-revalidate"

I can confirm that appending &bcache=1 to the URL will set the Cache-Control as expected, so this definitely is caused by http://git.wikimedia.org/commitdiff/operations%2Fpuppet.git/ce1f2b638ab2a09097ffe207ec6dc35c3823bc1b

(In reply to Michael M. from comment #2)

I can confirm that appending &bcache=1 to the URL will set the Cache-Control
as expected, so this definitely is caused by
http://git.wikimedia.org/commitdiff/operations%2Fpuppet.git/
ce1f2b638ab2a09097ffe207ec6dc35c3823bc1b

Thanks for investigating.

Mark: Any comments, as you worked on that change?

Mark: Any comments, as you worked on that change?

(In reply to Andre Klapper from comment #4)

Mark: Any comments, as you worked on that change?

That's an old change (2013) so he might have forgotten ;)

Krinkle/Roan/Trevor: Thoughts here on the right cache settings?

That change simply puts the same behaviour in place that was there with the Squid cluster before Varnish.

The problem is that we don't have separate Cache-Control headers for _our caches_ vs _clients_ in MediaWiki, and never have had. So MediaWiki's Cache-Control header is targeted at our caches, and Varnish replaces that header with one that for most URLs doesn't allow caching (just like our Squid config did). Unfortunately, Varnish can only guess from the URL.

metatron wrote:

If this is caused by this lines (as Michael M. stated):

sub vcl_deliver {

/* Override the Cache-Control header for wiki content pages */
if (req.url ~ "(?i)^/w(iki)?/.*"
    && req.url !~ "^/wiki/Special\:Banner(Controller|ListLoader)"
    && req.url !~ "(?i)^/w/(extensions/.*|api\.php)"
    && req.url !~ "(?i)bcache=1") {
    set resp.http.Cache-Control = "private, s-maxage=0, max-age=0, must-revalidate";
}

}

Why not just simply add a regex to meet the directives of the request?
Request-url and query-string are available at present; the "new" parameter bcache is respected, why not maxage/s-maxage?
IMHO at least "private" should be removed for requested .js/.css pages or for action "raw". This would allow proxies/local browsers to intelligently set caching. "private" + "must revalidate" leaves no elbowroom for systems to guess the right things.

https://meta.wikimedia.org/w/index.php?title=User:Hedonil/Test/XTools.js&action=raw&ctype=text/javascript&maxage=86400&smaxage=86400

max-age and s-maxage aren't really relevant in this issue and have been mostly obsoleted by the fact that we now allow full Varnish/Squid caching for action=raw (and are automatically purged after edits, the same way we purge the regular article views of pages).

However that only applies to logged-out users. For logged-in users, action=raw, similar to regular page views, always bypass cache.

We should fix this so that on regular wikis (e.g. not private read-restricted wikis) action=raw responses are publicly cached so that they can be completely handled by Varnish instead of requiring an needless roundtrip through Apache/PHP/MediaWiki.

Is there any plan to let the maxage parameter work correctly? Currently it still returns a Cache-Control header with max-age=0 despite explicitly setting it to a higher value. Using bcache=1 isn't changing the behavior either.

A quick count shows I have ~106 calls to either importScript or mw.loader.load in my [[https://en.wikipedia.org/wiki/User:AfroThundr3007730/common.js|common.js]] currently. It would be really awesome if all those requests could be cached instead of being loaded from scratch every time I open a tab (of which I usually have dozens up at a time). Granted, my use case is not a typical one, but the software should support Cache-Control with a max-age > 0 for user loaded resources, especially if we use something like &maxage=86400 in the URI (which I'm not currently, since that parameter doesn't even work).

@AfroThundr3007730 There are no plans to do that currently. These cannot be safely cached for security and privacy reasons, as such they are intentionally set to 0.

Note that max-age=0,private does not mean they are not cached. It simply means they are not unconditionally re-used by the CDN and your browser, which is not the same as caching.

Your browser does cache these, and does re-use the downloaded script between pages. The only thing it does is transfer a very small message in the background when loading a page to check if the script has changed since your last page view (this means edits will immediately apply, which is nice).

The scripts are not re-downloaded every time you view a page, and there is no need to add any bcache, maxage or smaxage parameters to MediaWiki urls, these do not improve performance anymore. Performance is our default, as much as possible.

The scripts are not re-downloaded every time you view a page, and there is no need to add any bcache, maxage or smaxage parameters to MediaWiki urls, these do not improve performance anymore. Performance is our default, as much as possible.

So, are maxage and smaxage obsolete? There some docs that still mention them, notably in the raw action section here:
https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php#Raw

The docs seems to suggest this should be better:

mw.loader.load("https://pl.wikipedia.org/w/index.php?action=raw&ctype=text/css&smaxage=86400&maxage=259200&title=Wikipedysta:Msz2001/sourcecode-links.css", "text/css");

Then this:

mw.loader.load("https://pl.wikipedia.org/w/index.php?action=raw&ctype=text/css&title=Wikipedysta:Msz2001/sourcecode-links.css", "text/css");

But looking at the headers and the fact that the raw call sometimes sets cookies, it seems docs are wrong, right? :-)

In T71460#8947620, @Nux wrote:

[…] There some docs that still mention them, notably in the raw action section here: https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php#Raw

The docs seems to suggest this should be better:

mw.loader.load("https://pl.wikipedia.org/w/index.php?action=raw&ctype=text/css&smaxage=86400&maxage=259200&title=Wikipedysta:Msz2001/sourcecode-links.css", "text/css");

Then this:

mw.loader.load("https://pl.wikipedia.org/w/index.php?action=raw&ctype=text/css&title=Wikipedysta:Msz2001/sourcecode-links.css", "text/css");

But looking at the headers and the fact that the raw call sometimes sets cookies, it seems docs are wrong, right? :-)

Indeed, when logged-out, both of these URLs enjoy the same CDN caching, and neither of them permits unrestricted browser caching. A notable difference is that when the page is edited, only the second one will automatically be purged and updated. The first one will stay out of date on the CDN because its URL is non-standard (not "canonical"), and so it is not known when we save an edit that this URL might exist in the cache, as there are infinite variations one could make with these parameters.

When logged-in, action=raw is not cached by the CDN, no matter which parameters are set.

The only thing these parameters do, is make the URL non-standard, and thus its CDN cache entry (for logged-out browsers) will remain stale for up to 24 hours after editing.