[bmn__]

In response to the reported RFC violation, elving@AWS writes: "I agree that's unconventional and unfortunate." My corporate bullshit detector is off the scale.

In earlier times, we would have both the ability and the balls to treat that unwillingness to uphold the rules we all set out with as damage to the Internet, and route around it. But sadly, AWS has become too big to fail, so the engineers introduce special cases into their products and deploy them.

[mmahemoff]

To the contrary, I think it's actually a refreshingly honest response. A "corporate bullshit" response would be to ignore it altogether, try to argue it's a feature not a bug, or give a canned statement about how we respect the environment and want the world to be a better place.

The AWS support is explicitly acknowledging it's an issue, while giving a rational reason why it probably won't be fixed (even if you disagree with the reason). The back-compat concern is unfortunate but a good argument can be made it's not in users' interests either (beyond being just a cost to AWS to implement the change).

[cm2187]

But can they even change it without risking to break tens of thousands of websites?

[mmahemoff]

They could, by versioning the API (e.g. add a /v2/ to all paths), but that would benefit no-one and should only be done alongside any number of much more important changes.

[bpicolo]

That opens a whole new can of worms. They have not deprecated a single part of the s3 API ever, in history (okay I'm partially lying, the SOAP API is now officially deprecated in the sense that they won't add new features to it).

They're not going to change it just for the sake of some minor path issues that have a workaround. (Side note: They tend to uses headers rather than paths for API declarations). I have personally been bit by this same issue, but I would never recommend they change pieces of the service to accommodate it. It's handled easily in client code. What they could do is make an obvious "gotchas" section of documentation

AWS has done a tremendous job of getting things right-enough the first time. They have never killed an AWS service. They'd need a much bigger reason to version an API.

[Aissen]

Isn't the API so huge that you could just configure a bucket (default-off) to behave properly ?

[jrochkind1]

Eh, URL/URI escaping is an interesting example, because people have been doing inconsistent and sometimes standards-problematic things with it pretty much as long as they existed. And indeed it's been a perpetual pain and problem. (just one example read up on `&` and `;`, and whether `&` can/should/must be escaped in what contexts; that's not the only one, `+` is another long-standing one). So not a great example of how everyone used to always be consistently standards-compliant in "earlier times", more like a counter-example. I don't think it's unique, my experience is not that everything used to be more consistent and standards compliant in "earlier times" than it is now, when it comes to the web, if anything the reverse.

[kinkrtyavimoodh]

How is this 'corporate bullshit'? Corporate BS is about giving vague circumlocutionary responses that try to just press all the right PR buttons.

This is the opposite of that.

[viraptor]

When were these "earlier times" for the web? Not during browser wars, that's for sure. Not when web2.0 started with crazy ideas about rest. Not during flash-everywhere era. Etc...