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

Respond with problems by default in aiohttp. #952

Merged
merged 11 commits into from
Jun 14, 2019

Conversation

cognifloyd
Copy link
Contributor

@cognifloyd cognifloyd commented May 22, 2019

AioHttp is not responding with problems yet. This uses an aiohttp middleware to handle exceptions and return a problem response.

Done:

  • Handle all exceptions handled by aiohttp to make sure they return problem json.
  • Fix the Unauthorized/OAuthProblem return not having problem json body
  • All werkzeug and aiohttp exceptions are converted to problem json responses preserving status/description/title.
  • All exceptions become problem json.
  • All current tests pass without modification.
  • Add tests for problem+json output when using aiohttp. Reuses the fixture and overall logic from test_errors.

Open questions:

Changes proposed in this pull request:

  • Return problems by default in aiohttp.
  • Send the debug logs and tracebacks like aiohttp does.
  • Drop oauth_problem_middleware in favor of handling all the problem output in problems_middleware because oauth_problem_middleware didn't actually return valid problem json, but this does.

Fix the exception handling so that if someone raises either
HTTPRedirection (3xx) or HTTPSuccessful (2xx) exceptions, they do not
get transformed into a problem with 500 Internal Server Error.
Fix the order of the problem middlewares so that the
oauth_problem_middleware can handle the auth problems first.

Also make sure to catch any werkzeug Exceptions, as OAuthProblem
subclasses a werkzeug exception, and others might mistakenly use the
werkzeug exceptions instead of the aiohttp exceptions.
The generic werkzeug handling works better because it generates valid
problem json. oauth_problem_middleware just passed the description in
the response body with the problem json content type.

Also renames error_to_problem_middleware to probems_middleware.
Also, clean up the detail output to ensure that detail messages are
helpful by default.
@cognifloyd cognifloyd force-pushed the aiohttp_problems branch 2 times, most recently from 561e467 to 39b7564 Compare May 24, 2019 04:25
The test cannot pass without revisiting how aiohttp_api uses _cast_body.
Instead of using the response content_type, it is casting the body based
on the openapi spec defined mediatype, which does not match in this case
when trying to return application/problem+json.

This also leaves an open question: How should problems be serialized if
the spec defines a format other than application/problem+json, or
application/json, etc? Here, a simple plain/text triggers the issue.

Ultimate reason for skipping the test (recorded in the test):

  aiohttp_api.get_connexion_response uses _cast_body to stringify the
  dict directly instead of using json.dumps. This differs from flask
  usage, where there is no _cast_body.
@cognifloyd
Copy link
Contributor Author

This is ready for review, and hopefully to be merged :)

@jmcs
Copy link
Contributor

jmcs commented Jun 14, 2019

👍

@jmcs jmcs merged commit 890fe9a into spec-first:master Jun 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants