Your counter on an HTTPS page

Your site is on HTTPS. Your visitors see a padlock. Then you paste in something from another site, and the padlock goes away — or the thing you pasted simply does not appear.

That is mixed content, and it is worth ten minutes of understanding because it silently breaks a lot of old embedded widgets.

What browsers do about it

A page loaded over HTTPS is not allowed to quietly pull pieces of itself over plain HTTP. An eavesdropper who can alter an unencrypted image request can alter what your visitors see, so the browser refuses to let the two mix.

For images and scripts, modern browsers either upgrade the request to HTTPS on their own or block it outright. Which of the two you get depends on the browser and the type of resource, and neither outcome is one you want to depend on.

Where Stats4U stands

Handled, in two places. The script has the address of the counting endpoint written into it as HTTPS, so every request it makes is encrypted regardless of how the page that loaded it was served. And the server answers plain HTTP with a permanent redirect to HTTPS — checked while writing this, both for the script and for the counter image itself.

So a counter embedded with a current snippet will not break your padlock, and there is nothing you need to configure.

The one case that can still bite

If somebody once copied the counter script into your own site rather than linking to it — which was a common habit, and there are pages doing it to this day — then you are running a frozen copy from whenever that happened. An old enough copy has a plain HTTP address inside it, and no amount of fixing on our side reaches it.

Two minutes to check: view the source of your page and search for http:// followed by our domain. If you find one, replace that whole embed with a current snippet from your statistics page.

While you are there, it is worth linking the script rather than hosting a copy of it at all. There is a separate post about why, and it applies to far more than counters.