On: Amazon S3 Path Deprecation Plan – The Rest of the ...

[inopinatus]

If we're talking textbooks, well then. This is a textbook case for the 301 HTTP response code.

[jasonkester → inopinatus]

The old REST-style S3 URLs are specifically excluded from being able to redirect:

https://docs.aws.amazon.com/AmazonS3/latest/dev/how-to-page-...

You can create a new bucket or switch your existing one to "Static Website Hosting" mode to enable the ability to 301 your content going forward. But the URL for the "website" version isn't the same as the REST URL. And again, there's no way to redirect from the old naming scheme to the new one.

If you have content that you've ever linked with one of those URLs, it's stuck there forever.

[codetrotter → jasonkester]

> And again, there's no way to redirect from the old naming scheme to the new one.

For customers, no. For Amazon itself, yes. And I think that is what parent commenter meant. That Amazon should 301 all requests that are using old paths.

[xchaotic → codetrotter]

It's not that simple, unfortunately - it won't work for the old dotted addresses and S3 is not HTTP

[inopinatus → jasonkester]

This isn't a restriction if you're AWS and looking to give more customers a soft landing over an extended deprecation timeframe.

The certificate concern some are raising is also a furphy.

[masklinn → inopinatus]

Except for all the dotted bucket names which can't be redirected because the result will always trigger a certificate error.

[AdamJacobMuller → masklinn]

That's not inherently accurate.

You can do inline generation of LetsEncrypt certificates with bucket-name-specific CN/SAN.

The fact that bucket names could contain characters which are wholly invalid as DNS labels is a bigger issue.