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

Adding dict interface to Response may accidentally break "if response:" check #2772

Closed
hubo1016 opened this issue Feb 27, 2018 · 5 comments
Closed
Labels

Comments

@hubo1016
Copy link
Contributor

When solving #2246, a dict-like interface is added to Response (and StreamResponse). It is convenient, but there is a side effect: a response object was previous True, but now an empty response object is False. This is quite surprising for developers who are not reading the documents carefully, so I think warnings should be added to document that these kind of objects must be tested with is None.

Considering this piece of code:

response = await call_middle_ware()
if not response:
    return await default_response()
else:
    return response

This piece of code call a middle ware, using its returning value as the final return value. If the middle_ware returns nothing, provides a default response.

But this breaks on 3.x because Response object is now a dict-like object, it contains a __len__ method, so a newly created Response object is actually False. The code must be modified to:

response = await call_middle_ware()
if response is not None:
    return await default_response()
else:
    return response
@asvetlov
Copy link
Member

I don't think we can do anything here.
If your function returns either response or None (aiohttp itself has no such API calls BTW) you have check it for is None or is not None.

@hubo1016 hubo1016 changed the title Adding dict interface to Response may accidentally break some code Adding dict interface to Response may accidentally break "if response:" check Feb 27, 2018
@hubo1016
Copy link
Contributor Author

@asvetlov Yes, I mean maybe we should provide more warnings about this change, since this is just released a few days ago. Some old code may appear to be working except middle-ware return values are always discarded. It is bad because some middle-wares are doing security checks, if this change accidentally bypass the security check, there will be serious security issues.

I think a special warning in the document and the next release note is necessary?

@asvetlov
Copy link
Member

The change is a part of aiohttp 3.0 release (2 weeks old).
A time for release note update is gone, the ship has sailed.
But if you have a feeling what documentation update can help -- please make a Pull Request.

@hubo1016
Copy link
Contributor Author

hubo1016 commented Mar 1, 2018

It looks like nothing could be done so I'm closing this.

@hubo1016 hubo1016 closed this as completed Mar 1, 2018
@lock
Copy link

lock bot commented Oct 28, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a [new issue] for related bugs.
If you feel like there's important points made in this discussion, please include those exceprts into that [new issue].
[new issue]: https://github.com/aio-libs/aiohttp/issues/new

@lock lock bot added the outdated label Oct 28, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 28, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants