A counter on an HTTPS page

A site is on HTTPS. Visitors see a padlock. Then something from another site gets pasted in, and the padlock goes away — or the pasted thing 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 the 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 happens depends on the browser and the type of resource, and neither outcome is safe 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 the padlock, and there is nothing to configure.

The one case that can still bite

If somebody once copied the counter script into the site itself rather than linking to it — which was a common habit, and there are pages doing it to this day — then what runs there is 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 the page and search for http:// followed by our domain. A hit there means the whole embed should be replaced with a current snippet from the statistics page.

And while the source is open: linking the script beats hosting a copy of it at all. There is a separate post about why, and it applies to far more than counters.