81–90 of 91 posts
I'm not sure what the other option is here? Keep old defaults and hope users update? I wouldn't be happy to find out they did it /just/ to break third-party S3 providers but it seems like it's an easy enough thing to turn it off right? I'm just not sure how comfortable I am with the phrasing here (or maybe I'm reading too much into it).
I'm not sure what the other option is here? Keep old defaults and hope users update? I wouldn't be happy to find out they did it /just/ to break third-party S3 providers but it seems like it's an easy enough thing to turn it off right? I'm just not sure how comfortable I am with the phrasing here (or maybe I'm reading too much into it).
The other option is not being overly strict with the data you receive from a client, especially when dealing with a protocol which is not a standard.
My guess is the client has options you pass in, they added a new default (or changed one, I’m not clear on that), and the new default sends something up to the server (header/param/etc) asking for the server to send back the new checksum header, the server doesn’t respond with the header, the client errors out.
Earlier quoted context omitted.
Less charitable or More cynical? How is Amazon supposed to track a 3rd party pulling their SDK and then reverse-engineering their own service side to work with the SDK? Assuming we're all okay with that premise to begin with, all sorts of other questions start popping up. Do these 3rd parties get veto power over a feature they can't support? Can they delay a launch if they need more time to make their reverse-enginee…
Requiring a header "just because you sniffed it to usually be there" is not Amazon being cynical, it's creatively-developing-overly-strict-checks. And it happens on the side of the S3-compatible service. If your service no longer works with the AWS SDK because you crash at `headers["content-md5"]` just because "it seemed a good way to make things more correct" - it is on you to fix it, IMO. Like, this changeset https…
Earlier quoted context omitted.
The other option is not being overly strict with the data you receive from a client, especially when dealing with a protocol which is not a standard.
I think the issue is that the client (the SDK) is complaining about a missing header it’s expecting to receive due to a new default in the client. My guess is the client has options you pass in, they added a new default (or changed one, I’m not clear on that), and the new default sends something up to the server (header/param/etc) asking for the server to send back the new checksum header, the server doesn’t respond…
Earlier quoted context omitted.
Requiring a header "just because you sniffed it to usually be there" is not Amazon being cynical, it's creatively-developing-overly-strict-checks. And it happens on the side of the S3-compatible service. If your service no longer works with the AWS SDK because you crash at `headers["content-md5"]` just because "it seemed a good way to make things more correct" - it is on you to fix it, IMO. Like, this changeset https…
I think you misread my response. I think assuming Amazon did this to hurt “s3 compatible” services is cynical. Amazon implemented a feature, well within their rights. Writing a blog post saying they “broke backwards compatibility” is cynical and disingenuous. Amazon never committed to supporting any random use of their SDK.
I'm confused. Why Cloudflare et al. won't release a package in pypi named boto-r2 or something, pinned to the last compatible version with the added benefit of setting the endpoint by default? It seems asinine to rely on Amazon as not to break things from time to time.
Python and cloudflare generally don't see each other much
Okay, but I'd never expect an AWS SDK to remain backwards compatible with third-party services and would be leery about using an AWS SDK with anything but AWS. It's on the third parties to keep their S3-compatible API, well, compatible. On the client side, you just have to pin to an older version of the AWS SDK till whatever compatible service you're using updates, right? Also, this is the first I've heard of OpenDAL…
Okay, but I'd never expect an AWS SDK to remain backwards compatible with third-party services and would be leery about using an AWS SDK with anything but AWS. It's on the third parties to keep their S3-compatible API, well, compatible. On the client side, you just have to pin to an older version of the AWS SDK till whatever compatible service you're using updates, right? Also, this is the first I've heard of OpenDAL…
Agree too. Just because you can get something to work doesn’t mean it’s supported. Using an Amazon S3 library on a non-Amazon service is “works but isn’t supported.” Stick to only supported things if you want reliability.
Earlier quoted context omitted.
While I agree that the author is just whining about this situation and that AWS did nothing wrong, I'd argue that a change in defaults is a breaking change.
https://xkcd.com/1172/
That's closer changing default key-binding. Anyways, all I'm saying - I would have considered it a breaking change because it changes default behavior.
Earlier quoted context omitted.
https://xkcd.com/1172/
I don't think that's the case? AWS didn't fix a bug or removed some UB. That's closer changing default key-binding. Anyways, all I'm saying - I would have considered it a breaking change because it changes default behavior.