Skip to content
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

Constraint_Error on unknown status code #384

Open
Rombobeorn opened this issue Sep 23, 2024 · 0 comments
Open

Constraint_Error on unknown status code #384

Rombobeorn opened this issue Sep 23, 2024 · 0 comments
Assignees
Labels

Comments

@Rombobeorn
Copy link

If a request sent with AWS.Client.Get is answered with a status code that AWS doesn't recognize, it results in Constraint_Error instead of correct handling of the class of the response.

RFC 9110 section 15 says:

HTTP status codes are extensible. A client is not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, a client MUST understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent to the x00 status code of that class.

For example, if a client receives an unrecognized status code of 471, it can see from the first digit that there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) status code. The response message will usually contain a representation that explains the status.

Values outside the range 100..599 are invalid. Implementations often use three-digit integer values outside of that range (i.e., 600..999) for internal communication of non-HTTP status (e.g., library errors). A client that receives a response with an invalid status code SHOULD process the response as if it had a 5xx (Server Error) status code.

AWS.Client does not treat status code 471 as 400. It propagates Constraint_Error with the message «bad input for 'Value: "S471"». For a client program to comply with the specification it has to parse the exception message to get the class of the status code. In some cases it may be impossible to recover even after parsing the exception message, because the rest of the response has been discarded.

@TurboGit TurboGit self-assigned this Nov 25, 2024
@TurboGit TurboGit added the bug label Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants