math doesn't render on https pages about dokuwiki-plugin-mathjax

[liffiton]

I'm not sure this is an https problem. I use the plugin on a wiki that I access over https, and there are no issues. The plugin page on dokuwiki.org itself doesn't ever render the math, because the plugin isn't installed on that site.

The Mathjax documentation is referring to accessing Mathjax itself over https, but that is only necessary if you want it to be accessed that way -- a page served over https (the wiki page) will happily pull Mathjax from a non-ssl server.

Might there be some other difference between logged in and not on your wiki?

[hazelnusse]

Ok, it appears that mathjax is not enabled on the page I linked which is why the plugin:mathjax page wasn't showing rendered mathjax. With regards to the issue I was having, I was able to fix it by installing mathjax on my server and configuring the mathjax plugin to point to that directory.

When using the default MathJax.js from cdn, and I view a page with https, it doesn't render. Viewed with http it does. If I use the https link:
https://c328740.ssl.cf1.rackcdn.com/mathjax/latest/MathJax.js
then the math renders from both http and https.

If a page is viewed with https, do scripts that are referenced as http:// (unsecured) get converted to https requests? If so, this would explain the problem I was having because the CDN link is hosted on rackspace, which as the FAQ mentions, does not support https. That is the only explanation I can come up with.

[liffiton]

Ahh, perhaps it's a browser setting to reject the unsecured connection to the CDN from a secured page. It does work in my Firefox install, but not Chrome.

Yes, I see that in Firefox, one can set security.mixed_content.block_active_content, which is off by default but appears to be a new feature that may be enabled by default in the future. So currently, by default, Firefox appears to allow it.

Given that Chrome blocks it, Firefox likely will in the future, and other browsers probably do or will soon, it would be good to handle this. It looks like the only option, though, is to make the plugin's default URL the https CDN URL, which is a bit inelegant and potentially confusing to users. Let me know if you can think of any better solutions. I'll at the very least add a note to the plugin documentation page.

Thanks for reporting this, and sorry I jumped to an incorrect conclusion at first.