'Response' object has no attribute 'status_code' in wsgi.py with websockets #1210

bclark8923 · 2016-02-16T19:13:19Z

I start my app using

gunicorn --worker-class eventlet -w 1 server:app --bind="127.0.0.1:5000"

And when using Flack-SocketIO for websockets I often get an error with Gunicorn not returning from a function properly

[2016-01-30 10:20:53 -0800] [7330] [ERROR] Error handling request
Traceback (most recent call last):
  File "/Users/brianclark/Desktop/Projects/HDP/application/api/venv/lib/python2.7/site-packages/gunicorn/workers/async.py", line 52, in handle
    self.handle_request(listener_name, req, client, addr)
  File "/Users/brianclark/Desktop/Projects/HDP/application/api/venv/lib/python2.7/site-packages/gunicorn/workers/async.py", line 114, in handle_request
    resp.close()
  File "/Users/brianclark/Desktop/Projects/HDP/application/api/venv/lib/python2.7/site-packages/gunicorn/http/wsgi.py", line 423, in close
    self.send_headers()
  File "/Users/brianclark/Desktop/Projects/HDP/application/api/venv/lib/python2.7/site-packages/gunicorn/http/wsgi.py", line 316, in send_headers
    tosend = self.default_headers()
  File "/Users/brianclark/Desktop/Projects/HDP/application/api/venv/lib/python2.7/site-packages/gunicorn/http/wsgi.py", line 297, in default_headers
    elif self.should_close():
  File "/Users/brianclark/Desktop/Projects/HDP/application/api/venv/lib/python2.7/site-packages/gunicorn/http/wsgi.py", line 230, in should_close
    if self.status_code < 200 or self.status_code in (204, 304):
AttributeError: 'Response' object has no attribute 'status_code'

Any advice on configurations I could use to fix this or is it a bug?

The text was updated successfully, but these errors were encountered:

benoitc · 2016-03-28T17:00:08Z

@bclark8923 do you have any application that could help to reproduce the issue?

bclark8923 · 2016-03-28T17:07:35Z

Yup! What would you like me to do?

On Monday, March 28, 2016, Benoit Chesneau [email protected] wrote:

@bclark8923 https://github.com/bclark8923 do you have any application
that could help to reproduce the issue?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1210 (comment)

Thanks,
Brian Clark
(248) 990 5616
www.hdphealth.com

Get to know me on Facebook https://facebook.com/bclark8923 & Twitter
https://twitter.com/blaurenceclark!

benoitc · 2016-03-28T17:12:00Z

@bclark8923 if it can be streamed so eventually i could include some part in a test that would help :)

Also which version of gunicorn are you using?

bclark8923 · 2016-03-28T17:16:06Z

Yes please! Email me [email protected] and 19.x of some sort can check
soon

On Monday, March 28, 2016, Benoit Chesneau [email protected] wrote:

@bclark8923 https://github.com/bclark8923 if it can be streamed so
eventually i could include some part in a test that would help :)

Also which version of gunicorn are you using?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1210 (comment)

Thanks,
Brian Clark
(248) 990 5616
www.hdphealth.com

Get to know me on Facebook https://facebook.com/bclark8923 & Twitter
https://twitter.com/blaurenceclark!

bclark8923 · 2016-03-28T17:40:23Z

Using version 19.4.5

kramer65 · 2016-04-15T10:15:44Z

I'm having the same issue. I'm using gunicorn version 18.0.

Any fix available already?

benoitc · 2016-04-15T12:03:44Z

if anyone have z code to reproduce it thatt would help :)

kramer65 · 2016-04-15T13:35:31Z

@benoitc - That makes sense.. ;-)

I'll fix something up next week and let you know!

kramer65 · 2016-04-15T15:24:41Z

@benoitc - Alright, I fixed something up before the weekend after all.

You can find the repo with instructions in the readme here: https://github.com/kramer65/gunicorn-error

btw: I'm using gunicorn version 18.0

tilgovi · 2016-04-18T23:51:34Z

Probably something needs to return gunicorn.workers.async.ALREADY_HANDLED or gunicorn will try to log the request as soon as the application returns from its WSGI handler. Gunicorn needs to know, instead, that the request is now handled entirely by the application.

tilgovi · 2016-04-18T23:52:40Z

Both of the examples in the "examples/websocket" directory return this constant from their WSGI handler.

kramer65 · 2016-04-24T14:40:04Z

@benoitc - Does the example to reproduce the error help you with finding the error? Can I be of any other assistance to help this be resolved?

benoitc · 2016-05-02T12:37:06Z

@kramer65 yes I reproduced the error.

So Gunicorn is a pure WSGI engine and is expecting a WSGI response containing a status:
https://github.com/benoitc/gunicorn/blob/master/gunicorn/http/wsgi.py#L242

(related to this code: https://github.com/benoitc/gunicorn/blob/master/gunicorn/workers/async.py#L103-L119)

As @tilgovi said you can bypass the response handling from gunicorn by returning ALREADY_HANDLED

As far as I read the code of flash socketio it is wrapping the flask application in socketio.Middleware which itself inheit from engineio.middleware.Middleware:
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/middleware.py

which return the wsgi application or their own own handler if it find the path:
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/middleware.py#L45-L52

So it return socketio.Server.handle_request on the websocket path:
https://github.com/miguelgrinberg/Flask-SocketIO/blob/master/flask_socketio/__init__.py#L144

which itself return engineio.Server.handle_request (lot of circular deps in this project...):
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/server.py#L184

At this point it appears that neither socket.handle_get_request or socket. handle_post_request set the status:
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/socket.py#L69-L96

And then an error may happen here:
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/server.py#L251-L252

since it can return a response without having set a status or anything. I can see that the upgrade use the same websocket object as in our example:
https://github.com/benoitc/gunicorn/blob/master/examples/websocket/websocket.py

I think that instead of returning the final r here:
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/server.py#L251-L252

It should probably return ALREADY_HANDLED like there:
https://github.com/benoitc/gunicorn/blob/master/examples/websocket/websocket.py#L115

Just a guess anyway since that code is quite difficult to read. Hopefully it will helps.

benoitc · 2016-05-02T12:38:07Z

@kramer65 let me know about the status of this ticket for you anyway :)

miguelgrinberg · 2016-05-07T20:31:16Z

@benoitc the ALREADY_HANDLED constant is specific to gunicorn. Eventlet has its own version of this constant, defined in a different way: https://github.com/eventlet/eventlet/blob/2cd5f1d9aea53efb4526e7185017bdcc84732588/eventlet/wsgi.py#L69.

The r value that you were following through the code returns evenlet's ALREADY_HANDLED when the websocket connection ends. This is handled automatically by eventlet: https://github.com/eventlet/eventlet/blob/2cd5f1d9aea53efb4526e7185017bdcc84732588/eventlet/websocket.py#L135.

Gunicorn should (I think) recognize eventlet's ALREADY_HANDLED constant in addition to its own and handle it in the same way. I think that will address this problem.

lequangdzung · 2016-05-26T23:28:28Z

It's great if you can fix this issue. I'm running flask-socketio & gunicorn on my production and don't want to lost data.

harm-devries · 2016-06-29T21:30:13Z

I am experiencing similar problems, and was wondering if there is any news on this issue?

kramer65 · 2016-06-30T09:30:17Z

@benoitc - Do you think the suggestion as made by @miguelgrinberg above (to let Gunicorn recognize eventlet's ALREADY_HANDLED constant in addition to its own and handle it in the same way) is a good idea?

tilgovi · 2016-06-30T23:57:20Z

@kramer65 if you can find a way to cleanly add support for that, I think it makes sense for the eventlet worker to handle it.

Right now the logic to handle this is a bit buried inside gunicorn.workers.async.AsyncWorker#handle_request but maybe that could be handled with indirection via static property that the eventlet worker can override, or by calling an instance method to check already handled by any worker-specific logic that might exist, with the base class doing as it does now.

kramer65 · 2016-08-23T08:17:25Z

@tilgovi - It has been a while since you send me your message, but I wanted to respond to this after all. The problem is that I kinda hit my limit in what I can do for this. I really have no clue how to proceed to solve this.

In the meantime my logs are filled with error messages like the one below, so I do have every reason to put some energy in having this solved. I just don't fully understand what the exact cause of the problem is, let alone that I understand how I could solve this.

If anybody wants to get into contact I would be happy to discuss the issue, and then I might be able to be of a bit more help than I am now.

2016-08-23 08:07:16 [2185] [ERROR] Error handling request
Traceback (most recent call last):
  File "/var/www/imd/venv/local/lib/python2.7/site-packages/gunicorn/workers/async.py", line 45, in handle
    self.handle_request(listener, req, client, addr)
  File "/var/www/imd/venv/local/lib/python2.7/site-packages/gunicorn/workers/async.py", line 102, in handle_request
    resp.close()
  File "/var/www/imd/venv/local/lib/python2.7/site-packages/gunicorn/http/wsgi.py", line 369, in close
    self.send_headers()
  File "/var/www/imd/venv/local/lib/python2.7/site-packages/gunicorn/http/wsgi.py", line 284, in send_headers
    tosend = self.default_headers()
  File "/var/www/imd/venv/local/lib/python2.7/site-packages/gunicorn/http/wsgi.py", line 265, in default_headers
    elif self.should_close():
  File "/var/www/imd/venv/local/lib/python2.7/site-packages/gunicorn/http/wsgi.py", line 198, in should_close
    if self.status_code < 200 or self.status_code in (204, 304):
AttributeError: 'Response' object has no attribute 'status_code'

qwexvf · 2016-10-19T11:40:17Z

did one fixed it ?.....

kramer65 · 2016-10-19T11:50:33Z

@qwexvf - Unfortunately I didn't. My logs are still filling up with errors. :-(

Anybody else?

qwexvf · 2016-10-19T12:58:05Z

@kramer65 i see. i've been waiting this for ages, if anyone has the fix please share with us! thanks!

Hum4n01d · 2016-11-19T01:08:22Z

any updates?

stefaang · 2016-12-06T15:22:15Z

I'm sure there are cleaner ways to fix this, but at least it's a start.

qwexvf · 2016-12-06T18:17:17Z

@stefaang thanks im gonna try thought it!

eddie-dunn · 2017-02-17T15:46:31Z

When will the fix for this be released on PyPI?

benoitc · 2017-02-17T17:38:59Z

tomorrow

…

On Fri, 17 Feb 2017 at 16:46, Eddie ***@***.***> wrote: When will the fix for this be released on PyPI? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1210 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAA4ogTRMF7EfR25G6gLrktOdh_iA4Ciks5rdcDYgaJpZM4HbcdP> .

jocms · 2017-02-20T17:18:54Z

Has it been released?

eddie-dunn · 2017-02-21T09:27:34Z

https://pypi.python.org/pypi/gunicorn

No :(

juliedavila · 2017-02-22T16:23:56Z

@benoitc any word on the update being pushed to pypi?

benoitc · 2017-02-22T16:54:42Z

@defionscode i will make a release in on thursday morning (tomorrow).

juliedavila · 2017-02-22T16:57:15Z

Excellent, thank you

…

On Wed, Feb 22, 2017 at 11:54 AM Benoit Chesneau ***@***.***> wrote: @defionscode <https://github.com/defionscode> i will make a release in on thursday morning (tomorrow). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1210 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEcrYp6QfVpWXhG14f4M-lPDHMn0cFncks5rfGhWgaJpZM4HbcdP> .

ghost · 2017-03-02T10:42:33Z

Has this fix been released?

benoitc · 2017-03-02T11:11:31Z

@Decker108 status is tracked by #1471 . It will be released today...

nicgirault · 2020-06-22T10:07:05Z

This bug is still happening on my side with the latest version 19 and 20 of gunicorn. Was it supposed to be fixed @benoitc ?

andyDoucette · 2023-10-26T06:02:09Z

Please re-open. This bug is still very much active, even with gunicorn==21.2.0.

tilgovi · 2023-12-28T02:11:21Z

Re-opened and assigned to me.

A new protocol, such as WebSockets or HTTP/2, may manage the framing of multiple messages or requests of that protocol over a single connection. - Close connections after completion of any upgraded response. - Close connections after a response with status code less than 200. Any such response should be only for a protocol upgrade since applications never see any `Expect` header. - Ensure that the `status_code` member always exists on instances of the `Response` class (close #1210).

A new protocol, such as WebSockets or HTTP/2, may manage the framing of multiple messages or requests of that protocol over a single connection. Once the WSGI callable returns, the connection should close. - Close connections after completion of any upgraded response. - Close connections after a response with status code less than 200. Any such response should be only for a protocol upgrade since applications never see any `Expect` header. - Ensure that the `status_code` member always exists on instances of the `Response` class (close #1210).

A new protocol, such as WebSockets or HTTP/2, may manage the framing of multiple messages or requests of that protocol over a single connection, but the connection should close once the WSGI callable returns. - Close connections after completion of any upgraded response. - Close connections after a response with status code less than 200. Any such response should be only for a protocol upgrade since applications never see any `Expect` header. - Ensure that the `status_code` member always exists on instances of the `Response` class (close #1210).

tilgovi · 2023-12-28T02:35:08Z

I think this could happen if the application raises an exception when handling a request before it starts a response. Gunicorn tries to figure out if the response was started and the headers should be sent but the status code is not defined yet. I believe I've fixed this issue in #3126 while fixing an unrelated issue with protocol upgrades (e.g. WebSockets).

bclark8923 mentioned this issue Feb 16, 2016

AttributeError: 'Response' object has no attribute 'status_code' miguelgrinberg/Flask-SocketIO#223

Closed

benoitc added Feedback Requested Discussion Investigation labels May 2, 2016

tilgovi added the help wanted Open for everyone. You do not need permission to work on these. May need familiarity with codebase. label Jun 30, 2016

miguelgrinberg mentioned this issue Aug 8, 2016

Socket disconnect event not always fired miguelgrinberg/python-socketio#38

Closed

aviaryan mentioned this issue Oct 7, 2016

Gunicorn error: 'Response' object has no attribute 'status_code' fossasia/open-event-server#2455

Closed

stefaang mentioned this issue Dec 6, 2016

add support for eventlets _AlreadyHandled object #1406

Merged

miguelgrinberg mentioned this issue Dec 16, 2016

Run error with uwsgi and gevent miguelgrinberg/Flask-SocketIO#381

Closed

benoitc closed this as completed in #1406 Dec 21, 2016

stefaang mentioned this issue Feb 23, 2017

Working with Heroku, Programming in Flask with gunicorn and a little of socketio I have this issue: #1419

Closed

BoWuGit mentioned this issue Aug 9, 2018

Old bug reproduced：'Response' object has no attribute 'status_code' in wsgi.py with websockets #1852

Open

tilgovi reopened this Dec 28, 2023

tilgovi self-assigned this Dec 28, 2023

tilgovi mentioned this issue Dec 28, 2023

Force connection close after protocol upgrade #3126

Open

benoitc closed this as completed Aug 6, 2024

'Response' object has no attribute 'status_code' in wsgi.py with websockets #1210

'Response' object has no attribute 'status_code' in wsgi.py with websockets #1210

Comments

bclark8923 commented Feb 16, 2016

benoitc commented Mar 28, 2016

bclark8923 commented Mar 28, 2016

benoitc commented Mar 28, 2016

bclark8923 commented Mar 28, 2016

bclark8923 commented Mar 28, 2016

kramer65 commented Apr 15, 2016 • edited Loading

benoitc commented Apr 15, 2016

kramer65 commented Apr 15, 2016

kramer65 commented Apr 15, 2016 • edited Loading

tilgovi commented Apr 18, 2016

tilgovi commented Apr 18, 2016

kramer65 commented Apr 24, 2016

benoitc commented May 2, 2016

benoitc commented May 2, 2016

miguelgrinberg commented May 7, 2016 • edited Loading

lequangdzung commented May 26, 2016

harm-devries commented Jun 29, 2016

kramer65 commented Jun 30, 2016 • edited Loading

tilgovi commented Jun 30, 2016

kramer65 commented Aug 23, 2016

qwexvf commented Oct 19, 2016

kramer65 commented Oct 19, 2016

qwexvf commented Oct 19, 2016

Hum4n01d commented Nov 19, 2016

stefaang commented Dec 6, 2016

qwexvf commented Dec 6, 2016

eddie-dunn commented Feb 17, 2017

benoitc commented Feb 17, 2017 via email

jocms commented Feb 20, 2017

eddie-dunn commented Feb 21, 2017

juliedavila commented Feb 22, 2017

benoitc commented Feb 22, 2017

juliedavila commented Feb 22, 2017 via email

ghost commented Mar 2, 2017 • edited by ghost Loading

benoitc commented Mar 2, 2017 • edited Loading

nicgirault commented Jun 22, 2020

andyDoucette commented Oct 26, 2023 • edited Loading

tilgovi commented Dec 28, 2023

tilgovi commented Dec 28, 2023

kramer65 commented Apr 15, 2016 •

edited

Loading

kramer65 commented Apr 15, 2016 •

edited

Loading

miguelgrinberg commented May 7, 2016 •

edited

Loading

kramer65 commented Jun 30, 2016 •

edited

Loading

ghost commented Mar 2, 2017 •

edited by ghost

Loading

benoitc commented Mar 2, 2017 •

edited

Loading

andyDoucette commented Oct 26, 2023 •

edited

Loading