The advantages offered by HTTPS access are widely advertised - and have led to envy between blog owners who publish to custom domains, and native BlogSpot blog owners proudly advertising their new HTTPS connectivity.
Long ago, we saw possibly malicious code which helps our readers avoid using country code aliases, to read our blogs from an aliased country. Recently, there was dodgy code which blocked HTTPS mode, to read a customised blog.
Now, we have custom code to force HTTPS access, for BlogSpot published blogs.
Along with providing code to help blog owners avoid country local domain aliasing, some marginally helpful hackers are providing code to help blog owners force reader access to HTTPS.
Some blog owners always wanted HTTPS to be used, to access their blog.
Some blog owners wanted their readers always using HTTPS to access their blogs, before forced HTTPS access became an option. They Googled, and found, semi helpful hackers who provide clever code to force the "HTTP --> HTTPS" redirection.
<script type='text/javascript'>
$(document).ready(function() {
$("a[href^='http://']").each(
function(){
if(this.href.indexOf(location.hostname) == -1) {
$(this).attr('target', '_blank');
}
}
);
$("a[href^='https://']").each
function(){
if(this.href.indexOf(location.hostname) == -1) {
$(this).attr('target', '_blank');
}
}
);
});
</script>
This is clever code - when only BlogSpot access is involved. When you add BlogSpot to custom domain redirection, it becomes another "404".
Adding this clever code is an excellent solution - until the blog owner forgets about it, and later upgrades to a non BlogSpot custom domain.
With a custom domain published blog, the redirection becomes a problem.
The added code contains no exception to permit custom domain published blogs to remain in HTTP mode. When accessing an otherwise properly setup custom domain published blog, from a reader using the "blogspot.com" URL, this prevents the BlogSpot to domain redirect from operating.
BlogSpot URLs, which should redirect to the HTTP published custom domain URL, instead redirect to a non existent HTTPS URL - and result in another "404". As the custom domain URL becomes more commonly used for a recently published blog, confusion increases when the rarer BlogSpot URL reference is encountered.
My blog has been using the domain URL for months, why is this happening now?
The problem involves dual redirection - to "https:" mode, and to the custom domain.
After painful problem diagnosis, we find the clever redirection code buried in template HTML - and we see that the blog reader is starting from the BlogSpot URL, and using the BlogSpot to domain redirection, to access the blog.
With blog access redirected to "https:" mode, then subsequently to the custom domain URL, the readers sees a "404" - because the custom domain URL is not available as "https:" content.
This problem will become increasingly rarer - but not extinct.
As self caused custom domain victims become rarer, this way of breaking ones own blog will become more obscure - and it's likely that some cases will go, unsolved. This will be similar to the problem of un migrated classic templates, which has increasingly less experienced support.
If you must install unsupported template tweaks into your template - consider the long term effects. Learn to recognise a problem that you have caused, to your own blog.
Not every helper will realise that you have added custom redirection code - and when looking at the problem code, when a problem is reported, will recognise it for what it is. Your problem may remain your problem - at least, until Blogger Engineering completes Blogger SSL integration (may this happen soon).
Some blog owners have added clever HTTP to HTTPS redirection code, acquired from helpful third party providers, installed in the template. When later publishing a blog to a custom domain, this code will prevent proper blog access - and as installed, may not be easily recognised.
https://productforums.google.com/forum/#!category-topic/blogger/bl5W39BKX4U
Posts
