Hello,
I don’t understand why but i get an issue when cache is active and https forced.
The both work fine separately but when i try to apply cache and to redirect http requests to https, only pages are correctly redirected to https, all assets like image, js and css files css are called via a http url and browsers block all those request.
I apply https redirection via htaccess, from the “Kirby secrets repo” and use simple cache configuration from the official documentation.
I tried to declare url in config.php but i had the same result…
Hi @Adspectus
Thanks for reply.
I don’t have any access to the apache config, the website will be hosted on an shared server.
This my htaccess :
# Kirby .htaccess
# rewrite rules
<IfModule mod_rewrite.c>
# enable awesome urls. i.e.:
# http://yourdomain.com/about-us/team
RewriteEngine on
# Redirect non www to www and Force https
RewriteCond %{HTTP_HOST} !=localhost
RewriteCond %{HTTP_HOST} ^www\. [NC,OR]
RewriteCond %{HTTPS} off
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L,NE]
# make sure to set the RewriteBase correctly
# if you are running the site in a subfolder;
# otherwise links or the entire site will break.
#
# If your homepage is http://yourdomain.com/mysite,
# set the RewriteBase to:
#
# RewriteBase /mysite
# In some environments it's necessary to
# set the RewriteBase to:
#
RewriteBase /
# block files and folders beginning with a dot, such as .git
# except for the .well-known folder, which is used for Let's Encrypt and security.txt
RewriteRule (^|/)\.(?!well-known\/) index.php [L]
# block all files in the content folder from being accessed directly
RewriteRule ^content/(.*) index.php [L]
# block all files in the site folder from being accessed directly
RewriteRule ^site/(.*) index.php [L]
# block direct access to Kirby and the Panel sources
RewriteRule ^kirby/(.*) index.php [L]
# make site links work
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php [L]
</IfModule>
# pass the Authorization header to PHP
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
# compress text file responses
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
</IfModule>
Hi @pixelijn
Thanks for reply.
It was my first direction…
I tried in private mode, after cache clearing and even in an another browser…
Same results. Each time.
Your rules seem to be working well and since you mentioned your problem is only with assets and media, there might be something else which interfere. You did not hard code “http://...” in your pages, did you? Are you using some kind of proxy, CDN or load balancer or is your provider doing so? Could you reveal the URL to your site to check for us?
Helas, for now i can’t. Work is in progress and url is confidential.
But i’m sure i had not harcoded url any where, i had only use kirby method like css(), toImages()->url(), etc…
I will check if provider apply CDN or something like that but i dont think so.
I use the 3.4.2 version with only few plugins : commentions, k3-image-clip, kirby builder and editor…
Those plugins seems me stables and i’m not sur they could be reponsibles.
May I suggest that you first update to the current version (3.4.4), so that we make sure that we are not trying to hunt down a possible bug that has long been fixed. You might also want to try with the pre-released 3.5.
If the issue is still there after the update, we can look further.
You mentioning the fact that both things (cache & https redirection) work alone, but not together, makes me think that kirby is at a certain point caching pages that contain http://.
I guess you already tried deleting your server cache? (I’ve only read “browser cache” in this thread). If not, I’d try that.
After deleting the server cache, please test if it’s working by first going to the http (not https) route and let it redirect, otherwise you might get a “false positive” in subsequent tests.
If that doesn’t help (or you already tried), my other hypothesis would be that kirby caches the “redirect page”. I’ll explain myself:
I’m not 100% sure how the mod_rewrite redirect works, but I’m beginning to think that it “just adds headers”. That would mean that your first http request is actually being redirected with a normal kirby page (at that point serving http) and some headers added by mod_rewrite - since this is the first time kirby renders the page, it also keeps the output and puts that into the cache (with all the http:// links). Then the browser follows the redirect header and asks for the https version, kirby looks at the cache and, since it doesn’t distinguish between http and https versions, happily serves you the cached http variant it just created in the first request that no-one actually saw.
You can test this hypothesis by refusing to ever serve kirby pages over http. You could do this by putting something like the following code to the top of your index.php (it has to be before the new Kirby call):
if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] == 'off') {
die('cannot serve http');
}
// here follows the normal kirby stuff
Then, once again, delete your server cache, and try going to a http:// route.
Thanks @texnixe and @rasteiner for your replies.
The rasteiner’s solution was the one. I had to manually clear the cache folder content on the server.
I supposed this folder was automatically cleared when i was activating and disabling cache… but not.
Thank you all, you rock !
I’m actually kinda surprised nr. 1 did it. I would have bet on nr. 2
However I think someone could / should investigate if cache doesn’t create problems in situations where people want to use both http and https to serve content, because it really would seem like Kirby doesn’t distinguish between the two when caching a page, and that would be a problem when a cached http version is served to a https request
In my quick test, some URLs were cached with the protocol, some without. Interestingly, those created with the css/js helpers without, but page urls with protocol. That is a bit weird, considering that assets didn’t work.
This is also what I saw once the cache and redirects were activated: the urls of the pages were updated in cache folders, but not those of assets like js, css, imgs …
I could see that the cache was managed domain by domain in the cache folder, maybe a lead would be to integrate the protocol in the name of the folders?
strange… Is that on 3.5?
I’ve just tried 3.4.4 starterkit, and it caches everything with protocol for me. And if you get a browser to actually load an http page (and not automatically change your url to https [chrome and firefox seem to do that now]) when no cache exists yet, kirby caches the http version and serves that to everyone from that moment on.
,
