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

131–140 of 146 posts

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

#131

Post by sroussey »

cthalupa wrote: post #85
lugg wrote: post #72

Earlier quoted context omitted.

ssl prevents that.

It explicitly does not. It means there are additional barriers to doing it - people would need to accept a bad cert (we already know the overwhelming majority will), or they would need to slip in their own CA that allows them to generate their own valid certs for MITM, but that is eminently doable for the Chinese government inside of China. They can then block all traffic for people that do not use the cert that allo…

They already have their own CA in browsers, so they can easily MITM. That’s why mobile apps will use certificate pinning to verify their server

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

#132

Post by phh »

rsanek wrote: post #56
kenhwang wrote: post #40

For anyone still confused to why AWS dominates the cloud market, it's because they're willing to grandfather features with a reasonable sunset horizon.

I'd say the momentum from having no competition in the space for nearly a decade is far more impactful.

I'd say it's a combination of both.

Not having competition means they got a lot of users, but having long-term feature support means people didn't run away.

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

#133

Post by parliament32 »

I still don't get why there was such an uproar about this: Amazon should just issue a "301 Moved Permanently" and be done with it.

If your app for some arcane reason doesn't understand an HTTP status code that's been around for 20 years... your code is bad and you should feel bad.

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

#134

Post by bitpow »

el_benhameen wrote: post #48

Kind of tangential, but is Bezos a programmer type? I thought he came from banking or the big 4. I’m curious if the “malloc for the internet” bit is verbatim.

He said once in a "fireside chat" with his brother that if Amazon went all to shit and never took off, he would probably be a perfectly happy software engineer somewhere.

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

#136

Post by syn0byte »

no_identd wrote: post #114
gumby wrote: post #111

Earlier quoted context omitted.

The fact the tcp (and it’s own institutional infrastructure) were already established is what made the whole OSI network effort even more enjoyably absurd. It was the last gasp of Big IT trying to take over the crazies. Most amusingly to me, it seemed only to be discussed in enterprise contexts and Very Important IT Journals. Such people were officially committed to deployment, while their own people were busy gettin…

You both get so much of this story so utterly… /not even/ __quite__ wrong, but more importantly, leave so much detail out that, if I didn't presume better(which I do! Would seem rather paranoid if I didn't.), I'd suspect lying by omission. All of this, which includes the story to follow, makes me—and I don't say this for exaggeration purposes, it really does have an emotional impact—very sad, although it doesn't surp…

There is this preoccupation in these documents with "applications" and "services" being an important part of the design of a network. I find it wrong to the point of troubling. Although granted I say this now only with the power of hind-sight.

With the power of hind-sight; Imagine an internet where Comcast, AT&T, et al, have such granular control over access to your infrastructure. Ala Cart billing based on each addressable service you happen to run for example. DNS hijacking on steroids as another. The development of new protocols for all but biggest "participating" organizations would be stillborn. Capitalism would have strangled the Internet baby in the crib long ago if we had "done it right."

The road to hell is paved with good intentions and these are some of the best intentions.

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

#137

Post by xchaotic »

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.

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

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

#139

Post by no_identd »

syn0byte wrote: post #136
no_identd wrote: post #114

Earlier quoted context omitted.

You both get so much of this story so utterly… /not even/ __quite__ wrong, but more importantly, leave so much detail out that, if I didn't presume better(which I do! Would seem rather paranoid if I didn't.), I'd suspect lying by omission. All of this, which includes the story to follow, makes me—and I don't say this for exaggeration purposes, it really does have an emotional impact—very sad, although it doesn't surp…

There is this preoccupation in these documents with "applications" and "services" being an important part of the design of a network. I find it wrong to the point of troubling. Although granted I say this now only with the power of hind-sight. With the power of hind-sight; Imagine an internet where Comcast, AT&T, et al, have such granular control over access to your infrastructure. Ala Cart billing based on each addr…

>Imagine an internet where Comcast, AT&T, et al, have such granular control over access to your infrastructure

They already do, tho, we call it port filtering & deep package inspection, and when they do that, people get mighty angry. ;)

Also, you seem to implicitly assume that they'd have come to gain as much power as they have now, but that seems doubtful, given how different this would work.

Also, I think you (unintentionally!) attack a strawman there - the point here consists more of matters like congestion control.

Besides:

I said what I said about hoping for cooperation between RINA & GNUnet for a reason:

RINA lacks the anti-censorship mechanisms of GNUnet, while GNUnet lacks some of the insights from RINA research.

And those anti-censorship mechanisms would make your point entirely moot.

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

#140

Post by syn0byte »

no_identd wrote: post #139
syn0byte wrote: post #136

Earlier quoted context omitted.

There is this preoccupation in these documents with "applications" and "services" being an important part of the design of a network. I find it wrong to the point of troubling. Although granted I say this now only with the power of hind-sight. With the power of hind-sight; Imagine an internet where Comcast, AT&T, et al, have such granular control over access to your infrastructure. Ala Cart billing based on each addr…

>Imagine an internet where Comcast, AT&T, et al, have such granular control over access to your infrastructure They already do, tho, we call it port filtering & deep package inspection, and when they do that, people get mighty angry. ;) Also, you seem to implicitly assume that they'd have come to gain as much power as they have now, but that seems doubtful, given how different this would work. Also, I think you (unin…

You're probably right about the straw man, but I wasn't trying to make an argument against better models. Just rationalizing why what we got ain't so bad after all.

Yes, they do all that now but it's kludgy, easy to detect, and a much more obvious overreach of their presumed authority. See Comcast/Sandvine fiasco.

As to the implicit assumption of the Telco's powers under such a system. History is my biggest "proof". It's a reasonable assumption given economic and games theory. At best it wouldn't have been the Telco's directly that ended up with the control. Someone would have and the result would still be the same.

How about this: How many terrible government regulations about filtering and censorship that are technologically infeasible with the current internet been not only technically possible, but fully fledged features of an objectively better design?

Again I'm not arguing against research and better designs, just rationalizing what we got.

Post reply on HN