Thread Starter
_ck_
(@_ck_)
Actually now that I think about it, the whole approach is bad.
Because a cached page for https and a cached page for http will have completely different links on the page.
If you use the same http cached page for https, non-relative links will be broken and take the user out of https when they follow (and visa versa)
You need to store (https) cached pages with the protocol appended and adjust htaccess as well for that situation.
Thread Starter
_ck_
(@_ck_)
Okay I see where index-https was added in 1.2
Doesn’t really address the original problem of true https detection but I guess nginx users can work around the environment problem.
Is there a better solution than this for nginx
inside http {
map $scheme $index {
default index;
https index-https;
}
then later in your location {
try_files /wp-content/cache/supercache/$host/$uri/$index.html
Note the $ on index to make it a string set by the map early on
That’s be best I can come up with because you should not use if statements in nginx when possible to avoid it.
Thread Starter
_ck_
(@_ck_)
A word of warning to those with proxies ahead of apache like nginx.
This will NOT work if you artificially set the HTTPS flag
RewriteCond %{HTTPS} on
Because apache hasn’t determined it on it’s own, the HTTPS flag is NOT equal to the environmental HTTPS variable, even though PHP after apache will see them as equal.
What you have to do instead is this
RewriteCond %{ENV:HTTPS} on
This is not the fault of wp-super-cache, just something to be aware of to save you time.
If you do it incorrectly, you will see Apache serving the index.html file to https connections instead of index-https.html
I do suggest that super-cache put the HTTPS rewrite rule first in it’s .htacess blocks though, kind of a waste to process all those other rules for each page load.