Non-2xx HTTP response code emits a `DANGER` validation error

The spec for the @http trait states that for the code:

The provided value SHOULD be between 100 and 599, and it MUST be between 100 and 999.

However, when providing a non-2xx value for code, such as 418 (why not?), the Smithy validation emits a DANGER message:

[DANGER] aws.protocoltests.misc#ResponseCodeRequiredOperation: Expected an `http` code in the 2xx range, but found 418 | HttpResponseCodeSemantics

Which is correct? The spec or the error?

[hambrosia]

I’m curious about how the redirect-based SAML flow is typically documented with Smithy. For example as shown here:

https://en.wikipedia.org/wiki/SAML_2.0#/media/File:Saml2-browser-sso-redirect-post.png

Let’s say a service has a /login endpoint that uses SAML with an an external identity provider. The service provider, or application that the user is interacting with, will redirect the user several times to the identity provider, and also maintain an endpoint to handle call backs from the identity provider.

Are there examples of using the auth trait to abstract over this?

[mtdowling]

We don’t have documentation specifically for that. I would not try to model those redirects in a Smithy model. They aren’t something your users call directly or should have to contend with. It’s something generated clients should handle on their behalf. It would be an implementation detail of a hypothetical SAML SSO redirect auth trait.

Putting the developer experience aside – you could try to model these things if you wanted to, you just need to suppress the validation. It’s not a blocker, but a nudge. If someone were trying to model SAML or something directly, and they had to stop and think about whether they should because of the validation, then I think the validator is working as intended.