Custom Domain Redirection, And "A" Referral Servers

One of the advantages of custom domain publishing, and the domain root to published URL redirection, used to be transparent redirection of the URLs.

As Blogger blog owners become more sophisticated with their blogs, and custom home pages (aka "landing pages"), become more popular, we have blog owners with concerns with home page access and the root redirection. We are also seeing concern with direct access to specific posts - with posts advertised, using the domain root URL.

In some cases, redirection only shows the reader the blog home page when the casual reader first sees the blog - even with a specific post being linked in the advertised URL.

With this blog, which is the redirect target of my domain, nitecruzr.net, this post "Custom Domain Redirection, And "A" Referral Servers" has a URL of "http://blogging.nitecruzr.net/2018/08/custom-domain-redirection-and-referral.html".

Since "blogging.nitecruzr.net" is the redirect target of the root redirect for "nitecruzr.net", this post "Custom Domain Redirection, And "A" Referral Servers" should have an alternate URL of "http://nitecruzr.net/2018/08/custom-domain-redirection-and-referral.html".

Click on the 4 links, in the 2 paragraphs immediately above, and compare the results - if you don't yet see the seriousness here. Please. It's not a cosmetic detail.

This post "Custom Domain Redirection, And "A" Referral Servers", advertised as "http://nitecruzr.net/2018/08/custom-domain-redirection-and-referral.html", redirects to "http://nitecruzr.net/".

This post "Custom Domain Redirection, And "A" Referral Servers", advertised as "https://nitecruzr.net/2018/08/custom-domain-redirection-and-referral.html", redirects to "https://nitecruzr.net/".

Note that this blog does not yet use "HTTPS Redirect", so if you click on a link to "Custom Domain Redirection, And "A" Referral Servers" you will see "http://blogging.nitecruzr.net/2018/08/custom-domain-redirection-and-referral.html".

Here's an example of the problem.

Here's a an example of this problem - diagnosed using a previous post blogging.nitecruzr.net/2016/08/delete-permanently-means-delete.html

A normal redirect - to "blogging.nitecruzr.net/2016/08/delete-permanently-means-delete.html"

http://blogging.nitecruzr.net/2016/08/delete-permanently-means-delete.html

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Expires: Mon, 23 Apr 2018 03:25:09 GMT
Date: Mon, 23 Apr 2018 03:25:09 GMT
Cache-Control: private, max-age=0
Last-Modified: Mon, 23 Apr 2018 03:23:01 GMT
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Server: GSE
Accept-Ranges: none
Vary: Accept-Encoding
Transfer-Encoding: chunked

A normal redirect - to the specific post, using HTTPS.



A broken redirect - to "blogging.nitecruzr.net"

http://nitecruzr.net/2016/08/delete-permanently-means-delete.html

HTTP/1.1 301 Moved Permanently
Location: http://blogging.nitecruzr.net
Date: Mon, 23 Apr 2018 03:23:18 GMT
Content-Type: text/html; charset=UTF-8
Server: ghs
Content-Length: 226
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN

http://blogging.nitecruzr.net

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Expires: Mon, 23 Apr 2018 03:23:19 GMT
Date: Mon, 23 Apr 2018 03:23:19 GMT
Cache-Control: private, max-age=0
Last-Modified: Mon, 23 Apr 2018 03:23:01 GMT
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Server: GSE
Accept-Ranges: none
Vary: Accept-Encoding
Transfer-Encoding: chunked

A broken redirect - to the blog home page, using HTTPS.



Unfortunately, some blog owners are observing that redirection of a specific root URL - maybe a custom landing page, or a specific post advertised using the root URL - appears to lead only to the home page of the published blog.

This is a problem with domain / website design, in general - and with Blogger custom domain design, in particular.

The domain root to published URL (for most blogs, the "www" host) appears to use a version of frame forwarding, with some blogs being reported.

I never recommend using Frame Forwarding, in the custom domain DNS setup.

One of the disadvantages of frame forwarding is that redirects using frame forwarding drop the post URL.

We've been seeing this problem reported, for several years.

The problem, rarely - but not never - reported, started several years ago. This was before HTTPS for BlogSpot - and even farther before HTTPS for custom domains - was rolled out.

This was shortly after we started observing other problems involved, in the deployment of HTTPS.

The first HTTPS issue was reported in 2014. HTTPS for BlogSpot was rolled out in 2015.

I'm betting we first saw reports of the post URL being lost, in the ""http://xxxxxxx.whatever.com/whatever.html" -> ... -> "https://www.whatever.com"" was maybe 2 years ago. During deployment of HTTPS.

My guess is that Blogger Engineers upgraded the domain root servers ("A" address) redirection code, to support HTTPS - and made a business decision to use frame forwarding.

From what I've seen of Blogger Engineering in general - and custom domain design in particular - I am convinced that if they decided that frame forwarding is necessary, it's necessary. Until they can correct the problem, that is. My advice to every domain owner to not use registrar supplied frame forwarding in the domain DNS, notwithstanding.

I can only hope that we will see this problem corrected, this decade. Remain optimistic - and report the problem, when it can be identified.

---

It appears that some of the #Blogger custom domain "A" address name servers are using "Frame Forwarding", instead of "Referral", to redirect the domain root to the published URL. Frame forwarding strips away the post address portion of the URL - leaving only the domain root.

Some blog owners use the domain root to advertise their blog posts - and are seeing only the blog home page, instead of the individual posts, when linking to the posts.

https://productforums.google.com/d/topic/blogger/NtQHoVNJ5PM/discussion

https://productforums.google.com/d/topic/blogger/pePwPhr_H-Y/discussion

https://productforums.google.com/forum/#!category-topic/blogger/pePwPhr_H-Y

https://productforums.google.com/forum/#!category-topic/blogger/nr-cIIgjBGg

HTTPS Availability For All All Blogger Blogs

After years of waiting, this blog is now readable, using HTTPS.

This blog, and others published using properly setup custom domains, now provides optional HTTPS connectivity - joining BlogSpot published blogs.

I looked at the Settings - Basic page of my Blogger dashboard, a couple hours ago.

Previously, I might see the HTTPS options "Availability" and "Redirect" when accessing my Draft Blogger dashboard. Now, both are there, in Production Blogger.

If you publish a blog, using a custom domain URL, you should see the new option too. It took 5 minutes, with my blog, to activate "HTTPS Availability".

RBS is now secure!



A couple hours ago, "HTTPS Availability" was offered, on my Blogger dashboard.

There are two options - HTTPS Availability, and HTTPS Redirect.

• HTTPS Availability lets your readers access your blog, using HTTP or HTTPS, as they choose. HTTPS Availability is now an option, for all blogs.
• HTTPS Redirect automatically requires all readers use HTTPS, to access your blog. HTTPS Redirect is an option, with HTTPS Availability enabled.

HTTPS Availability is now an option!



"HTTPS Availability" lets your readers, who use only HTTPS, connect to your blog. It's the first step in upgrading the web.

So, it's selected - and now we wait.



When you enable "HTTPS Availability" for a custom domain published blog, Google will setup an SSL certificate for the domain - free of charge. Just enable the option, and wait a few seconds - and your domain will be secure, with certificate.

Less than 5 minutes later, and I see the display updated.



"HTTPS Redirect" is now available, for this blog. "HTTPS Redirect" automatically requires all of your readers to use HTTPS, when reading your blog. It's the second step in upgrading the web.

So "HTTPS Availability" is now a reality. Common sense - and Blogger advice - tells me to take things slowly. I'll still allow HTTP connectivity, for readers who can't use HTTPS.

I next need to setup Search Console entries for this blog, using HTTPS.

For best results, the domain needs to be properly setup. Both the BlogSpot to domain redirection, and the domain root ("naked domain") to published URL redirection, can be complicated, with HTTPS offered for an improperly setup domain.

Also, remove any other custom installed redirecting code. Both code blocking local country redirection, and code blocking (or enabling) HTTPS redirection, will interfere with the HTTPS Redirect option.

And check your non Blogger accessories and features carefully. Blogger is not the last Internet service to provide this upgrade - and your blog will provide the best experience, for your readers, if all accessories and features also support HTTPS.

Test the blog and domain, in the many URLs.

With the blog published to the domain, and offering HTTPS connectivity, you'll have 6 URLs - all pointing to the blog. Make sure that all 6 work properly.

Right now, my test blog does provide HTTPS connectivity / redirect - though this blog does not, since I don't want broken links to third party services. Using my test blog, I have 6 URLs to check. Note that this blog is published as "blogging.nitecruzr.net" - not "techdict.nitecruzr.net", or "www.nitecruzr.net".

1. http://myspaceandmore.blogspot.com
2. http://nitecruzr.net
3. http://techdict.nitecruzr.net
4. https://myspaceandmore.blogspot.com
5. https://nitecruzr.net
6. https://techdict.nitecruzr.net

Your readers will be happiest, if all 6 URLs work - and all redirect to your blog. Again, your domain will probably use "www", in place of "blogging" or "techdict", in #3 and #6.

Be prepared to re publish the blog, for best results.

If you were using "HTTPS Redirect" for the BlogSpot URL, #2 and / or #5 many be "404". You may need to re publish the blog, and remove the BlogSpot "HTTP" to "HTTPS" redirect. The domain root redirect, and "HTTPS Redirect" for the domain, may conflict.

Activate "HTTPS Redirect" for the domain, with the BlogSpot URL having "HTTPS Redirect" enabled - and you may see this.



You will have 3 redirects, with HTTPS Redirect added.

1. The BlogSpot to domain redirect.
2. The domain root to published URL redirect.
3. The "HTTP" to "HTTPS" redirect.

All 3 redirects need to be addd in proper sequence - if you want the BlogSpot URLs, the domain root, and the published domain URL to all redirect to the blog.

With both the BlogSpot redirect, the domain root redirect, and the HTTPS redirect enabled, you may see an error when addressing the domain root. In that case, you'll have to re publish the blog to the domain.

1. Login to production Blogger ("www.blogger.com").
2. Publish the blog back to BlogSpot, by clicking on the "X".
3. Disable “HTTPS”, if necessary.
4. Re publish the blog to the "www" domain host.
5. Select the domain root redirect.

Be careful when editing the pages / posts / template.

One of the reasons why HTTPS took so long to be available with Blogger - and contrarily, why the entire web did not upgrade over night - is that other blogs and websites have not yet upgraded.

If your blog is to provide useful HTTPS connectivity, any accessories and features, that you depend on, must also offer HTTPS connectivity. If a non HTTPS link is present, your readers will see scary advice about "mixed content", and "unsafe" web pages.

Blogger provides "mixed content" warnings, in page / post / template editor, when appropriate - but read their warning very very carefully. Before you change a link from HTTP to HTTPS, you have to verify that the accessory linked will provide HTTPS connectivity.

The "Fix" option in the page / post / template editor "mixed content" warning will break accessories that don't yet provide HTTPS connectivity. Don't change links from HTTP to HTTPS, without verifying that they will support the change.

Understand the details, to ensure an effective migration.

If you can deal with the details, you'll have a secure domain - and you can now offer your readers SSL connectivity, to your custom domain published blog, using all 6 links above.

---

HTTPS Availability is now an option for all #Blogger blogs. I'll continue to offer HTTP, for readers who can't use HTTPS - but those who require HTTPS can now use it, to access this blog - and other custom domain published blogs.

Custom Domains And HTTPS Redirection Code

As most of us know, Blogger HTTPS support does not include custom domain publishing.

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

Blogger Magic - Adding Label Search URLs

One of the simplest ways to make a blog useful is to add label searches.

Adding label searches, in page / post text, is not easy - unless you know how to build the URLs. Here's a label search from this blog.

http://blogging.nitecruzr.net/search/label/Blogger%20Magic

All that I want, when using that label search, is to add another reference to my "Blogger Magic" post series.

"Blogger Magic" emphasises how easy it is, to use Blogger. How easy is it, to remember that syntax - to add a label link? Maybe, a "Blogger Magic" reference, in this post?

When you read a blog post, that has label references, look at the bottom of the post.

---

Please note the advice, at the bottom of the post.

---

Look in the post footer, for the "Labels" section.

Here's the bottom of another post, from this blog.

Here's the bottom of this post.



Note that not all blogs will provide a "Labels" posts section. That is an owner choice.

Look at a label link, in the "Labels" section of the post - when provided.

There's the bottom of two of my "Label Search" posts - "Blogger Magic - A Blog Within A Blog", followed by this post "Blogger Magic - Adding Label Search URLs". Now, look at the Labels links.

In most blogs, the Labels links would be labeled "Labels". I call mine "Topics". As owner of this blog, that is my personal choice.

Also, in most blogs, the "Labels" section will be found, in the post footer. Some blog owners have chosen to position their "Labels" in the post header. This, too, is their choice - and carries with it, some risk.

See "Label Search"?



Look in the browser status area, when hovering over the link caption.

Look at the "Topics" section. See "Label Search"? Hover the mouse cursor, over the "Label Search" link.

See the label search URL, in the browser status area?



Look in the browser status area, when hovering over the link caption.

Hover the mouse over "Label Search", and look in the browser status area.

blogging.nitecruzr.net/search/label/Label Search

For a blog using an HTTPS redirect, you might see a slightly different URL.

If this blog uses the "HTTPS: Redirect" option, you might see it slightly differently.

https://blogging.nitecruzr.net/search/label/Label%20Search

Click on either of the above 2 links. OK, I cheated with the second link - since this blog, right now, does not support HTTPS - and I obviously don't want you looking at an HTTPS Error display.

Whether HTTP - or HTTPS - is in use, there is the label search link.

Whichever you see - and decide to use - with your blog, there is a label search URL. Now, get a label search URL from your blog - and use the URL, in another page or post in your blog.

This post opens many links in new tabs / windows, intentionally.

BTW - and if you have clicked on any of the links above - and since you have apparently read to this point - I have to warn you that many of the links, above, are intentionally coded to open in a new tab / window. That is necessary, based on the nature of the links in this post.

Many of the links in this post are clickable, simply to illustrate to you the content in label searches - as opposed to links which lead you to additional information in the blog. So as not to lead you away from this post, you should not lose context after clicking on a link - as long as you simply close the new (illustrative) tab / window.

My sincere apologies, if my seemingly gratuitous opening of new tabs / windows inconveniences or offends you.

---

Some #Blogger blog owners want to use label search URLs, in page or post text. Getting a label search URL is easy enough, when you look in the post label search section - which is generally in the post footer.