-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Can't read response content after checking response.ok #5403
Comments
This syntax is invalid. Instead, it should be: msg = await response.text() |
Looking at the implementation, I think this is expected behaviour. Typical usage is:
The expectation appears to be that you would not want to read anything from the connection if |
Hmm, appears to be a fix for this issue: #3364 So, maybe it shouldn't apply to resp.ok? |
I think this is indeed a bug. The best way to fix it is to put the
I think it's not an expectation but something that's been overlooked during the review of #4711. cc @EvanKepner |
Thanks, updated, that was just "stupid copy/paste" :) |
This change makes it so accessing `ClientResponse.ok` only does the status code check. Prior to this commit, it'd call `ClientResponse.raise_for_status()` which in turn, closed the underlying TCP session whenever the status was 400 or higher making it effectively impossible to keep working with the response, including reading the HTTP response payload. PR #5404 by @adamko147 Fixes #5403 Co-authored-by: Sviatoslav Sydorenko <[email protected]>
…5407) This change makes it so accessing `ClientResponse.ok` only does the status code check. Prior to this commit, it'd call `ClientResponse.raise_for_status()` which in turn, closed the underlying TCP session whenever the status was 400 or higher making it effectively impossible to keep working with the response, including reading the HTTP response payload. PR #5404 by @adamko147 Fixes #5403 Co-authored-by: Sviatoslav Sydorenko <[email protected]> (cherry picked from commit 3250c5d) Co-authored-by: Adam Horacek <[email protected]>
This change makes it so accessing `ClientResponse.ok` only does the status code check. Prior to this commit, it'd call `ClientResponse.raise_for_status()` which in turn, closed the underlying TCP session whenever the status was 400 or higher making it effectively impossible to keep working with the response, including reading the HTTP response payload. PR aio-libs#5404 by @adamko147 Fixes aio-libs#5403 Co-authored-by: Sviatoslav Sydorenko <[email protected]>
This change makes it so accessing `ClientResponse.ok` only does the status code check. Prior to this commit, it'd call `ClientResponse.raise_for_status()` which in turn, closed the underlying TCP session whenever the status was 400 or higher making it effectively impossible to keep working with the response, including reading the HTTP response payload. PR aio-libs#5404 by @adamko147 Fixes aio-libs#5403 Co-authored-by: Sviatoslav Sydorenko <[email protected]>
This change makes it so accessing `ClientResponse.ok` only does the status code check. Prior to this commit, it'd call `ClientResponse.raise_for_status()` which in turn, closed the underlying TCP session whenever the status was 400 or higher making it effectively impossible to keep working with the response, including reading the HTTP response payload. PR aio-libs#5404 by @adamko147 Fixes aio-libs#5403 Co-authored-by: Sviatoslav Sydorenko <[email protected]>
🐞 Describe the bug
For failed requests, ClientResponse is "released" after calling to
resposne.ok
and therefore can't readresponse.text()
after checkingresponse.ok
💡 To Reproduce
does not work, while
works just fine
💡 Expected behavior
I'm not sure this is expected behaviour.
response.ok
is read-only property and I believe it should not change the state of the response object. Also, failed requests may contain response body, e.g. with error description, so I'm expectingawait response.text()
to work properly after checkingresponse.ok
📋 Your version of the Python
📋 Your version of the aiohttp/yarl/multidict distributions
The text was updated successfully, but these errors were encountered: