Hacker News new | ask | show | jobs
by BillinghamJ 2608 days ago
The point of that is solely for doing website hosting with S3 though - where you'll have a CNAME. Why would you name a bucket that way if you're not using it for the website hosting feature?
3 comments

Not too long ago, we used S3 to serve large amounts of publicly available data in webapps. We had hundreds of buckets with URL style names. Then the TLS fairy came along. Google began punishing websites without HTTPS and browsers prevented HTTPS pages from loading HTTP iframes.

Suddenly we had two options. Use CloudFront with hundreds of SSL certs, at great expense (in time and additional AWS fees), or change the names of all buckets to something without dots.

But aaaaah, S3 doesn't support renaming buckets. And we still had to support legacy applications anf legacy customers. So we ended up duplicating some buckets as needed. Because, you see, S3 also doesn't support having multiple aliases (symlinks) for the same bucket.

Our S3 bills went up by about 50%, but that was a lot cheaper than the CloudFront+HTTPS way.

The cynic in me thinks not having aliases/symlinks in S3 is a deliberate money-grabbing tactic.

It also comes up when working with buckets of others. Right now if you build a service that is supposed to fetch from a user supplied s3 bucket the path access was the safest.

Now one would need to hook the cert validation and ignore dots which can be quite tricky because deeply hidden in an ssl layer.

How does the S3 CLI handle this? Do they hook cert validation? (I assume they must actually validate HTTPS...)
Pretty sure you get a cert error or they still use paths. Boto (what it’s build on) has an open issue for this for a few years now.
You might be POSTing user uploads to uploads.example.com.

https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPO...

This could still use the CNAME trick though no?