A static digression

 After finally passing on various web site creation tools I figured I would do the simple thing:  post a static web site.

AWS allows you to use an S3 storage bucket as a static web site.  Sweet! What could be simpler?  I have a tool that allows me to map an S3 bucket into a Windows folder, so all I would have to do is update the folder to publish changes.  Even better, you can put Cloudfront in front of it which ensures HTTPS as well as HTTP requests are handled.

Sounds good ... but

1. The instructions (at least at that time) left out the key fact that your bucket has to have the same name as your domain.
2. My file uploader wasn't setting the metadata correctly.  That was fixable.
3. It's a bit confusing to pick the right kind of certificate for HTTPS (wildcard or root only).
4. "index.html" is only returned by default for the root bucket; so, for instance, https://www.above-the-garage.com/piano doesn't work - you have to specify https://www.above-the-garage.com/piano/index.html ; this broke some existing links out in the wild.
5. DNS

Now let's see if I can explain this.

In the beginning, web sites tended to have "www." in front, like this:

http://www.above-the-garage.com 

"www." specified the protocol - world wide web.  You could have file transfer ("ftp.") or actually any prefix you wanted.

About a year ago Google announced they would stop displaying the "www." part.  Sounded good.  I made sure the following variations would link to my site:

1. http://above-the-garage.com
2. https://above-the-garage.com
3. http://www.above-the-garage.com
4. https://www.above-the-garage.com

Unfortunately, one of those doesn't work!  It's #2.  And the reason is the certificate doesn't match.

And it turns out it can't match.

Here is an email from April 2019 from Pair Domains, my DNS provider, that explains things:

We are contacting you because there is a problem with DNS records for your

domain above-the-garage.com.

There is currently a CNAME record for @. DNS rules prohibit other records

from sharing the same host name with a CNAME record. With a record for @,

this means that MX records would not work and there could be e-mail

delivery problems for the domain.

We recently changed our DNS software, and the new software is more strict

about DNS rules. Before, CNAME records and MX records could coexist, but

not everyone would be able to actually deliver the e-mail. The new

software does not allow this, so if there is a CNAME for @, e-mail won't

work on the domain.

Well, I also use above-the-garage.com for email, and I want that to work, so I had to drop the CNAME which allowed www.above-the-garage.com to point to above-the-garage.com; and my cert was for above-the-garage.com (without the www.).

So what to do ... change DNS providers?  No, it looks like they are implementing the standard.  Aha!  Make the cert for the www version; and redirect any hits to the homepage to the https://www.above-the-garage.com name; the cert matches, and everything is great.  Except, sadly, case #2 above, where browsers see the https: label, and really want the cert to match the exact domain name.  It doesn't, so the redirect doesn't happen, and people get an error after it times out.  In general, this is probably not a big deal; but in the long run, people and browsers might enforce going to https://above-the-garage.com . Maybe I can put a second cert on there and all is well.  

The most important thing is what happens when you just type in "above-the-garage.com" to your browser address bar:  works in Chrome and Edge!

So, static web site mostly works.  w00t.

[Q9G9P4J]