[flother]

The article's from December 2017 and you can see from the response headers that it's hosted on GitHub Pages again.

There are plenty of gotchas when serving a static site via CloudFront. Let's say you have a page at example.com/foo/index.html. If you want it serve it from example.com/foo/ then you need to write a Lambda@Edge request function to handle the directory index — the article implies that CloudFront's default root objects handle this, but they don't. That's for the domain root only.

There's also the case of redirecting example.com/foo to example.com/foo/ (adding the trailing slash). That requires a Lambda@Edge response function. It's all a lot of fun to get working, but you do start to wonder if your static site really is static.

[fallenhitokiri]

Both problems you mentioned are solved by using S3 configured to serve the buckets contents as static site as origin for CloudFront.

While it’s not strictly CloudFront only doing the work, it’s still a static site.

[flother]

Ah, that explains it. I store my websites in private S3 buckets, and give CloudFront access using an IAM policy. I must need to jump through extra hoops because of that.

[joobus]

To get default index.html files to serve properly, use the http url from the static site pane in your s3 bucket setup. Don't use the bucket listed in the drop-down on cloudfront. Then it will work properly. You don't need a lambda function.

[rabidrat]

Hm, while I agree that there are some gotchas serving static sites via AWS, the one you mention seems to work fine for me. See e.g. https://visidata.org/releases/ which is definitely served via CloudFront and definitely does not use a Lambda@Edge request function.

[flother]

Well that's interesting. An AWS blog post from October 2017 says:

> CloudFront does allow you to specify a default root object (index.html), but it only works on the root of the website (such as http://www.example.com > http://www.example.com/index.html). It does not work on any subdirectory (such as http://www.example.com/about/). If you were to attempt to request this URL through CloudFront, CloudFront would do a S3 GetObject API call against a key that does not exist.

https://aws.amazon.com/blogs/compute/implementing-default-di...

A request for https://visidata.org/releases (no trailing slash) also results in an HTTP 302 to https://visidata.org/releases/ (with a trailing slash). Is there something other than Lambda@Edge functions handling this on visidata.org?