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

return new NotFoundResponse();

[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