Remove base url from global cache prefix

[juliusknorr]

Having the base url in the global cache prefix seems to have caused the various issues with the SCSSCacher/JSCombiner. The cache was not cleared properly when using multiple domains and for cases when the base url was fetched while running form the cli.

This PR moves the base url from the global prefix to the cache prefix itself, so when calling the clear method of any ICache, all entries will properly get removed.

It will also reduce the number of used cache keys, since we don't have duplicate keys for every base url now anymore.

Fix for #8705 - I think we should merge it in addition to #8714 since this will fix the root cause, that the cache was not cleared properly.

[MorrisJobke]

This still gives the full deps in my env and doesn't clear them properly. :/ Let me check the prefixes on CLI and web.

[MorrisJobke]

This still gives the full deps in my env and doesn't clear them properly. :/ Let me check the prefixes on CLI and web.

I needed to configure overwritehost to be localhost:8000 because on the CLI it was only localhost.

Having this set up the first request to that URL still results in a 404 and the followup requests show the proper file. :/ Still weird.

[MorrisJobke]

The weird thing: the file is properly rendered, but somewhere later a 404 is triggered:

{
"reqId": "8eRMrhk6ACNMqfkALk0m",
"level": 0,
"time": "2018-03-07T13:07:37+00:00",
"remoteAddr": "172.20.0.1",
"user": "admin",
"app": "no app in context",
"method": "GET",
"url": "/index.php/js/core/merged-template-prepend.js?v=b2f9666b-0",
"message": "JSCombiner: successfully cached: merged-template-prepend.js",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/604.5.6 (KHTML, like Gecko) Version/11.0.3 Safari/604.5.6",
"version": "14.0.0.1"
}

[MorrisJobke]

404 page is rendered here:

server/core/Controller/JsController.php

Line 74 in 4ef302c

returnnewNotFoundResponse();

[codecov]

Codecov Report

Merging #8716 into master will decrease coverage by 24.71%.
The diff coverage is 0%.

@@ Coverage Diff @@## master #8716 +/- ##
============================================
- Coverage 31.43% 6.72% -24.72% 
Complexity 25368 25368 ============================================
Files 1607 1607 Lines 95157 95153 -4 Branches 1379 1379 ============================================
- Hits 29917 6399 -23518 - Misses 65240 88754 +23514

Impacted Files	Coverage Δ	Complexity Δ
lib/private/Template/SCSSCacher.php	0% <0%> (-71.54%)	36 <0> (ø)
lib/private/Template/JSCombiner.php	0% <0%> (-87.5%)	31 <0> (ø)
lib/private/Server.php	1.76% <0%> (-15.92%)	282 <0> (ø)
apps/theming/lib/ThemingDefaults.php	0% <0%> (-91.05%)	46 <0> (ø)
lib/private/TemplateLayout.php	0% <0%> (ø)	49 <0> (ø)	⬇️
apps/dav/lib/CalDAV/Activity/Setting/Event.php	0% <0%> (-100%)	8% <0%> (ø)
.../Contacts/ContactsMenu/Providers/EMailProvider.php	0% <0%> (-100%)	4% <0%> (ø)
core/Controller/ContactsMenuController.php	0% <0%> (-100%)	4% <0%> (ø)
lib/private/Security/CSRF/CsrfTokenGenerator.php	0% <0%> (-100%)	2% <0%> (ø)
...eLimiting/Exception/RateLimitExceededException.php	0% <0%> (-100%)	1% <0%> (ø)
... and 622 more

[MorrisJobke]

The weird thing: the file is properly rendered, but somewhere later a 404 is triggered:

Not that weird ... this code is called before the "isCached" is called and thus fails to fetch it. Maybe there is another position where we should check for the file first.

[MorrisJobke]

@juliushaertl Still the same behavior with the most recent commit.

[MorrisJobke]

Okay - so the files are regenerated on the processing of the 404 template and not on the call to JsController::getJs method. Thus it fails on the first request and then is cached.

This happens first:

As this is a direct access to the "to be cached" location it fails and causes a 404 page to be rendered which properly fetches the asset through the JSCombiner (and not directly):

[MorrisJobke]

@juliushaertl I tested this by calling curl http://localhost:8000/index.php/js/core/merged-template-prepend.js\?v\=b2f9666b-0 directly ... don't know if this is supported, but I would think so, or is this only allowed to be called after the template is loaded (the template rendering causes the assets being compiled).

[juliusknorr]

don't know if this is supported, but I would think so, or is this only allowed to be called after the template is loaded (the template rendering causes the assets being compiled).

Yes, the template needs to be loaded first, since that will iterate over included js/scss files and then run the combiner/scss cacher.

[juliusknorr]

It would of course make sense to trigger that also for direct requests to the getJS route.

[MorrisJobke]

It works if I open run the repair step and call http://localhost:8000/apps/files/ - it does not work if I open http://localhost:8000/js/core/merged-template-prepend.js directly. Fine for me for now.

[MorrisJobke]

It would of course make sense to trigger that also for direct requests to the getJS route.

Let's do this in a followup PR.

[juliusknorr]

Ok great. Let me adjust the tests then.

[juliusknorr]

Done. Failing tests are unrelated.

[MorrisJobke]

Done. Failing tests are unrelated.

Indeed - composer failure :/

[juliusknorr]

backport at #8745