Make all i.sstatic.net links protocol-relative

Question

Stack Overflow has HTTPS in some places! However, this breaks most existing image links. Could those be made protocol-relative, or react to the requesting protocol, or just always use HTTPS?

The same applies to .sponsor-tag-img.

Answer 1

Not exactly as requested, but all image embeds are https:// now, as part of deploying HTTPS across the network. This causes fetching over HTTP/2 and results in a faster experience.

Answer 2

The just released Stack Overflow Unofficial Patch v1.14 includes a client-side work-around for this issue.

Ideally, such a work-around would intercept any requests for image files over HTTP and rewrite them to use HTTPS. However, while this is possible for a browser extension like HTTPS Everywhere, I'm not aware of any cross-browser way to do it with a simple user script like SOUP.

Instead, the way this work-around works is by detecting images that:

1. have failed to load,
2. have a http: URL on a page loaded over https:, and
3. are on a domain known to support HTTPS simply by changing the protocol in the URL.

Notably, condition #1 means that this work-around only applies if your browser is configured to block insecure images on secure pages. For Firefox, this setting is available on the about:config page as security.mixed_content.block_display_content. I'm not currently aware of any way to change this setting for other browsers.

This also means that you'll still get mixed-content errors in your browser error log; the work-around just reloads the images over HTTPS after they've failed to load over insecure HTTP.

Also, while SOUP does try to re-run the work-around code whenever new content is injected via AJAX or otherwise modified, it's possible that there may be some remaining cases where dynamically loaded images are not fixed properly. If you find any, please let me know.

The domains for which the work-around is enabled currently include:

• imgur.com (including stack.imgur.com), used for user-uploaded images using the SE editor's upload tool, as well as for user avatars uploaded via SE;

• gravatar.com, used for global user avatars (actually, gravatar images seem to be already loaded over HTTPS anyway, but I've included it just in case);

• facebook.com, used for avatars for users logging in via Facebook;

• wikimedia.org (including upload.wikimedia.org), a popular source of freely licensed images;

• sstatic.net, used for some SE interface graphics, such as site icons (mostly loaded over HTTPS already, but IIRC I found some broken ones when I tested this); and

• stackexchange.com and all other Stack Exchange sites (stackoverflow.com, superuser.com, serverfault.com, stackapps.com, askubuntu.com, mathoverflow.net), used e.g. for user flair images.

Some notable examples of domains to which the workaround is not applied include chart.apis.google.com (Google Charts, does not seem to support HTTPS) and imageshack.us (could be supported, but would require more complex URL mangling than just changing the protocol).

---

Just in case you're curious, here's the whole code, as included in SOUP v1.20.0:

if ( 'https:' != location.protocol ) return;
var urlRegex = /^http:\/\/(([a-z0-9\-]+\.)*((imgur|gravatar|facebook)\.com|wikimedia\.org|sstatic\.net|(stack(exchange|overflow|apps)|superuser|serverfault|askubuntu)\.com|mathoverflow\.net))\//i;
var fixImages = function (target) {
    $(target).find('img[src^="http://"]').each( function () {
        if ( ! urlRegex.test( this.src ) ) return;
        if ( ! this.complete || this.naturalWidth > 0 ) return;
        var newUrl = this.src.replace( urlRegex, 'https://$1/' );
        SOUP.log( 'soup mse221304 fixing img ' + this.src + ' -> ' + newUrl );
        this.src = newUrl;
    } );
};
SOUP.addContentFilter( fixImages, 'HTTPS image fix' );
$(document).on( 'mouseenter', '#user-menu', function () {
    SOUP.try( 'HTTPS image fix', fixImages, [this] );
} );