[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 ?