Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Amazon S3 Path Deprecation Plan – The Rest of the Story

aws.amazon.com

Post reply on HN
Print view View original

121–130 of 146 posts

Re: Amazon S3 Path Deprecation Plan – The Rest of the Story

#121

Post by masklinn »

nebulous1 wrote: post #102
masklinn wrote: post #98

Earlier quoted context omitted.

How do you handle conflicts when an other bucket name legitimately uses whichever replacement character you picked? Historically bucket names are supersets of DNS names. In fact, early 2018 Amazon modified the bucket naming rules in one of the older regions as the names that region allowed were completely inaccessible in vhost style (not just cert mismatch, the names were literally not expressible): > The legacy rule…

You don't allow them register whatever replacement character you pick?

> You don't allow them register whatever replacement character you pick?

1. it's a few years too late for that.

2. it makes very little sense and is not really workable, the set of valid characters in DNS name is limited and quite finite, you're suggesting amazon just bans e.g. z from bucket names (and not explaining what happens to all existing bucket names with a z in them).

Re: Amazon S3 Path Deprecation Plan – The Rest of the Story

#122

Post by jeffbarr »

nik736 wrote: post #108

"In this example, jbarr-public and jeffbarr-public are bucket names; /images/ritchie_and_thompson_pdp11.jpeg and /jeffbarr-public/classic_amazon_door_desk.png are object keys." I think this should be: "In this example, jbarr-public and jeffbarr-public are bucket names; /images/ritchie_and_thompson_pdp11.jpeg and /classic_amazon_door_desk.png are object keys."

You are correct; thanks for spotting this! All fixed.

Re: Amazon S3 Path Deprecation Plan – The Rest of the Story

#123

Post by [deleted] »

codetrotter wrote: post #113
jasonkester wrote: post #112

Earlier quoted context omitted.

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…

> 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.

[deleted]

Re: Amazon S3 Path Deprecation Plan – The Rest of the Story

#124

Post by masklinn »

inopinatus wrote: post #83
DVassallo wrote: post #2

Thank you for listening! The original plan was insane. The new one is sane. As I pointed out here https://twitter.com/dvassallo/status/1125549694778691584 thousands of printed books had references to V1 S3 URLs. Breaking them would have been a huge loss. Thank you!

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

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

Re: Amazon S3 Path Deprecation Plan – The Rest of the Story

#125

Post by ethagnawl »

DVassallo wrote: post #2

Thank you for listening! The original plan was insane. The new one is sane. As I pointed out here https://twitter.com/dvassallo/status/1125549694778691584 thousands of printed books had references to V1 S3 URLs. Breaking them would have been a huge loss. Thank you!

This announcement comes as a relief. I was already drafting the email I'd need to send to current/former clients, letting them know that they'd have to hire me (or someone else) to write/run a migration to update asset paths hardcoded in static HTML pages or risk broken assets going forward. IIRC, an older version of the Froala WYSIWYG editor didn't support uploads using "nested" object paths (e.g. bucket/post-1/photo.png) and VH paths, which is why I leaned on the path-style feature for a few projects. So, not only would the fix (for the projects using Froala) involve migrating the S3 objects, I'd also have to change application code and/or upgrade the Froala WYSIWYG editor.

Hindsight is 20/20, of course, but I'm (unpleasantly) surprised they didn't take the thousands of ways a hard cut-over would break the web before drafting and (softly) announcing the initial plan.

Re: Amazon S3 Path Deprecation Plan – The Rest of the Story

#126

Post by LgWoodenBadger »

masklinn wrote: post #120
DenisM wrote: post #118

Earlier quoted context omitted.

s3.amazonaws.com/abc-xyz -> abc-xyz.s3.amazonaws.com s3.amazonaws.com/abc-x.y.z -> only punycodeof(abc-x.y.z).encoded.s3.amazonaws.com

Punycode encodes ascii characters literally, so punycodeof(abc-x.y.z) is abc-x.y.z which fixes nothing whatsoever.

well how about somethingLikePunyCodeButNotActuallyPunyCodeSoThatEveryoneUnderstandsHisPointAndDoesntFocusOnIrrelevantTechnicalities(abc-x.y.z) ?

Re: Amazon S3 Path Deprecation Plan – The Rest of the Story

#127

Post by Thaxll »

chipperyman573 wrote: post #15

Still doesn't help with domain censorship. This was discussed in-depth in the other thread from yesterday, but TLDR, it's a lot harder to block https://s3.amazonaws.com/tiananmen-square-facts than https://tiananmen-square-facts.s3.amazonaws.com because DNS lookups are made before HTTPS kicks in.

Why is it harder, just block s3.amazonaws.com that's it. I don't think countries that block domains care about s3.amazonaws.com.

Re: Amazon S3 Path Deprecation Plan – The Rest of the Story

#129

Post by snarf21 »

blaisio wrote: post #44

This is interesting for a few reasons. IMHO, the original deprecation plan was reasonable. Not generous, but reasonable. Especially compared to what other cloud providers (eg. Google Cloud) have done. It did seem like a diversion from their normal practice of obsessively supporting old stuff for as long as possible, but it really wasn't too bad. Responding to feedback, publicly, and explaining what they were trying t…

It is good to see them modifying their plan. I get the need to have stable APIs but the reciprocal challenge of updating APIs to handle new use cases and scale better.

The think that I wish companies would do in this case is the following. Set a hard date for when the change will happen (hopefully giving at least 18 months). Then, send a weekly (monthly) report detailing the number of things a customer has that isn't compliance. For example, every week AWS could send a report summary to the account holder of any URL accessed via the path structure. They could then login to see more details. A lot of systems are sprawling and people are busy putting out fires so a constant reminder and hard end date keeps it top of mind for people so you don't end up working through the weekend trying to get something back up and running. I wish Apple would do this for deprecated APIs (e.g.), email me regularly that I have an app in the store that is using deprecated APIs and they will stop working on date X.

Re: Amazon S3 Path Deprecation Plan – The Rest of the Story

#130

Post by rjsw »

gumby wrote: post #70
omeid2 wrote: post #64

Earlier quoted context omitted.

It is a shame that OSI didn't happen though and instead we have an ad-hoc mess of layered cake without clear boundaries as demonstrated by OSI Model.

I don't agree: the OSI protocols were the classic camel-is-a-horse-designed-by-committee: heavyweight and looked like a pain to use. Looked like, as I never saw a working stack. The IETF/RFC/Working Code/Interop(RIP) approach has given V4 incredibly long legs. At least the OSI model itself kinda survived.

ISODE [1] worked, and it was usable before there were commercial ISPs offering TCP/IP services.

[1] https://en.wikipedia.org/wiki/ISO_Development_Environment

Post reply on HN