david-perez

These are the _concrete_ choices I'm making for the implementation of the Rust sSDK. Feel free to close the issue if these choices are good and compliant with the specs....

@adamthom-amzn Sounds good. That is in fact the same S3-like use case that a user of our sSDK wants to build: https://github.com/awslabs/smithy-rs/pull/1023#discussion_r777568429 But they're using restXml, which currently also [says...

While `_CUSTOM_IMAGE` works, it's not documented: https://docs.aws.amazon.com/amplify/latest/userguide/environment-variables.html

> No, you'd serialize the union value inside the outer structure. Ah, my bad. This is how we're doing it. How do we serialize the union when the user has...

> Unions can’t be assigned a default value, so to bind them as httpPayload, they must be required. I'm confused, is this implying that `httpPayload` implies the member shape must...

> The spec leaves open room for implementations to [not pad](https://datatracker.ietf.org/doc/html/rfc4648#section-5) The part of the spec you link to is for `base64url`, which "should not be regarded as the same...

> as leaving off padding does no harm whatsoever in practice My use case is in trying to decide whether a specification for [a service interface modelling language](https://awslabs.github.io/smithy/1.0/spec/index.html) should reject...

I acknowledge that padding is generally useless nowadays in most use cases, but my interpretation of the spec is that _by default_, unpadded base64-encoded data should be rejected unless you...

> and Rust seems to be alone in its handling here Here is some data to back up this claim. This is how some major programming languages' standard libraries (or...

Oh wow, I didn't know about that paper nor had I considered using this behavior for attacks. I am now entirely convinced that rejecting unpadded encoded data should be the...