-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Precisions related to the httpResponseCode
trait
#2135
Comments
We could make sure to emit a warning when found elsewhere. |
Thanks, for your answer. Still, could an implementation return |
It’s undefined right now, but we should define it. I think it should be 2xx only for httpResponseCode. In practice, the clients I can remember looking at their implementations wouldn’t work with anything outside of 2xx. Clients are also supposed to be able to handle unmodeled HTTP errors. Intermediaries outside your frameworks might throttle, return 503, etc. Typically with errors, there’s some kind of signal it’s an error (e.g, a special header or something like __type). In the case of intermediaries, you can’t really enforce that, so it becomes harder if not impossible to unambiguously know if it’s a successful response or a random error. |
Could you provide precisions related to the values that should be valid at runtime, regarding
httpResponseCode
trait, in the AWS protocols that support it ?In particular, considering the following :
Foo
operation is successful, is400
considered valid dynamic value for thecode
member of FooOutput ?Foo
operation fails withClientError
, are200
and500
considered valid dynamic values for thecode
member ofClientError
?Foo
operation fails withServerError
, are200
and400
considered valid dynamic values for thecode
member ofServerError
?The text was updated successfully, but these errors were encountered: