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

Default error handlers should return 422 status code to client? #38

Closed
sloria opened this issue Apr 13, 2015 · 2 comments

Comments

@sloria
Copy link
Member

commented Apr 13, 2015

Currently, error handlers return a 400 response. It may be more appropriate to return a 422, which is typically used for ValidationErrors.

From RFC 4918:

The 422 (Unprocessable Entity) status code means the server
understands the content type of the request entity (hence a
415(Unsupported Media Type) status code is inappropriate), and the
syntax of the request entity is correct (thus a 400 (Bad Request)
status code is inappropriate) but was unable to process the contained
instructions. For example, this error condition may occur if an XML
request body contains well-formed (i.e., syntactically correct), but
semantically erroneous, XML instructions.

@sloria sloria closed this in c435ad6 Apr 15, 2015

@rajatkhanduja

This comment has been minimized.

Copy link

commented Aug 2, 2015

I am not an expert at this, but I'd like to discuss more about this.

Quoting a stackoverflow answer, RFC 7231 has the following to say about status code 400 (Bad Request)

The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something that is perceived to be
a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).

Wouldn't "invalid request message framing" cover the scenarios where a ValidationError would be raised?

@ghost

This comment has been minimized.

Copy link

commented Jul 18, 2016

This is old, but I also believe validation errors should be returning 400. 422 is a webdav extension and is not included in RFC 7231 https://tools.ietf.org/html/rfc7231

sloria added a commit that referenced this issue Sep 30, 2018

Bump sphinx-issues from 1.0.0 to 1.1.0 (#292)
Bumps [sphinx-issues](https://github.com/sloria/sphinx-issues) from 1.0.0 to 1.1.0.
<details>
<summary>Commits</summary>

- [`6a9da3a`](sloria/sphinx-issues@6a9da3a) Bump version and update changelog
- [`5b5259e`](sloria/sphinx-issues@5b5259e) Bring tox more in line with travis
- [`b4b36a3`](sloria/sphinx-issues@b4b36a3) Merge pull request [#44](https://github-redirect.dependabot.com/sloria/sphinx-issues/issues/44) from sloria/add-cve-role
- [`73b2090`](sloria/sphinx-issues@73b2090) Add :cve: role for linking to CVEs on Mitre
- [`cebf09a`](sloria/sphinx-issues@cebf09a) Bump invoke from 1.1.1 to 1.2.0
- [`7aaf7e7`](sloria/sphinx-issues@7aaf7e7) Bump tox from 3.2.1 to 3.3.0
- [`3c16b57`](sloria/sphinx-issues@3c16b57) Bump pytest from 3.7.4 to 3.8.0
- [`22b3146`](sloria/sphinx-issues@22b3146) Bump pytest from 3.7.3 to 3.7.4
- [`8169910`](sloria/sphinx-issues@8169910) Bump pytest from 3.7.2 to 3.7.3
- [`09272b3`](sloria/sphinx-issues@09272b3) Merge pull request [#38](https://github-redirect.dependabot.com/sloria/sphinx-issues/issues/38) from sloria/dependabot/pip/pytest-3.7.2
- Additional commits viewable in [compare view](sloria/sphinx-issues@1.0.0...1.1.0)
</details>
<br />

[![Dependabot compatibility score](https://api.dependabot.com/badges/compatibility_score?dependency-name=sphinx-issues&package-manager=pip&previous-version=1.0.0&new-version=1.1.0)](https://dependabot.com/compatibility-score.html?dependency-name=sphinx-issues&package-manager=pip&previous-version=1.0.0&new-version=1.1.0)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

Dependabot will **not** automatically merge this PR because it includes a minor update to a production dependency.

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot ignore this [patch|minor|major] version` will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Pull request limits (per update run and/or open at any time)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)

Finally, you can contact us by mentioning @dependabot.

</details>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.