Gunicorn: Объект Response не имеет атрибута status_code в wsgi.py с веб-сокетами.

@ bclark8923 есть ли у вас какое-нибудь приложение, которое могло бы помочь воспроизвести проблему?

Ага! Что ты хочешь, чтобы я сделал?

В понедельник, 28 марта 2016 г., Бенуа Шено [email protected] написал:

@ bclark8923 https://github.com/bclark8923 у вас есть какое-нибудь приложение
что может помочь воспроизвести проблему?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/benoitc/gunicorn/issues/1210#issuecomment -202484667

Спасибо,
Брайан Кларк
(248) 990 5616
www.hdphealth.com

Познакомьтесь со мной на Facebook https://facebook.com/bclark8923 и Twitter
https://twitter.com/blaurenceclark!

@ bclark8923, если его можно транслировать, так что в конечном итоге я мог бы включить какую-то часть в тест, который мог бы помочь :)

Какую версию Gunicorn вы используете?

Да, пожалуйста! Напишите мне на [email protected] и 19.x какой нибудь может проверить
скоро

В понедельник, 28 марта 2016 г., Бенуа Шено [email protected] написал:

@ bclark8923 https://github.com/bclark8923, если его можно транслировать так
в конце концов я мог бы включить какую-то часть в тест, который бы помог :)

Какую версию Gunicorn вы используете?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/benoitc/gunicorn/issues/1210#issuecomment -202492005

Спасибо,
Брайан Кларк
(248) 990 5616
www.hdphealth.com

Познакомьтесь со мной на Facebook https://facebook.com/bclark8923 и Twitter
https://twitter.com/blaurenceclark!

Используется версия 19.4.5

У меня такая же проблема. Я использую Gunicorn версии 18.0.

Какие-нибудь исправления уже доступны?

если у кого-то есть z-код для его воспроизведения, это поможет :)

@benoitc - В этом есть смысл .. ;-)

Я кое-что исправлю на следующей неделе и дам вам знать!

@benoitc - Хорошо, я все-таки кое-что исправил до выходных.

Вы можете найти репо с инструкциями в readme здесь: https://github.com/kramer65/gunicorn-error

кстати: я использую Gunicorn версии 18.0

Вероятно, что-то нужно вернуть gunicorn.workers.async.ALREADY_HANDLED иначе gunicorn попытается зарегистрировать запрос, как только приложение вернется из своего обработчика WSGI. Вместо этого Gunicorn необходимо знать, что теперь запрос полностью обрабатывается приложением.

Оба примера в каталоге «examples / websocket» возвращают эту константу из своего обработчика WSGI.

@benoitc - Помогает ли вам в поиске ошибки пример воспроизведения ошибки? Могу ли я чем-нибудь помочь, чтобы решить эту проблему?

@ kramer65 да воспроизвел ошибку.

Итак, Gunicorn - это чистый движок WSGI и ожидает ответа WSGI, содержащего статус:
https://github.com/benoitc/gunicorn/blob/master/gunicorn/http/wsgi.py#L242

(связанный с этим кодом: https://github.com/benoitc/gunicorn/blob/master/gunicorn/workers/async.py#L103-L119)

Как сказал @tilgovi, вы можете обойти обработку ответа от gunicorn, вернув ALREADY_HANDLED

Насколько я читал код flash socketio, он оборачивает приложение flask в socketio.Middleware которое само наследуется от engineio.middleware.Middleware :
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/middleware.py

которые возвращают приложение wsgi или собственный обработчик, если он находит путь:
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/middleware.py#L45 -L52

Таким образом, он возвращает socketio.Server.handle_request по пути веб-сокета:
https://github.com/miguelgrinberg/Flask-SocketIO/blob/master/flask_socketio/__init__.py#L144

который сам возвращает engineio.Server.handle_request (много циклических зависимостей в этом проекте ...):
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/server.py#L184

На данный момент кажется, что ни socket.handle_get_request ни socket. handle_post_request устанавливают статус:
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/socket.py#L69 -L96

И тут может произойти ошибка:
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/server.py#L251 -L252

поскольку он может возвращать ответ, не задавая статуса или чего-то еще. Я вижу, что при обновлении используется тот же объект websocket, что и в нашем примере:
https://github.com/benoitc/gunicorn/blob/master/examples/websocket/websocket.py

Я думаю, что вместо того, чтобы возвращать последние r здесь:
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/server.py#L251 -L252

Вероятно, он должен вернуть ALREADY_HANDLED например:
https://github.com/benoitc/gunicorn/blob/master/examples/websocket/websocket.py#L115

В любом случае, это просто предположение, поскольку этот код довольно сложно читать. Надеюсь, это поможет.

@ kramer65 все равно дайте мне знать о статусе этого билета :)

@benoitc константа ALREADY_HANDLED специфична для Gunicorn. У Eventlet есть собственная версия этой константы, определенная другим способом: https://github.com/eventlet/eventlet/blob/2cd5f1d9aea53efb4526e7185017bdcc84732588/eventlet/wsgi.py#L69.

Значение r которое вы использовали в коде, возвращает значение ALREADY_HANDLED дажелета при завершении соединения с веб-сокетом. Это обрабатывается автоматически eventlet: https://github.com/eventlet/eventlet/blob/2cd5f1d9aea53efb4526e7185017bdcc84732588/eventlet/websocket.py#L135.

Gunicorn должен (я думаю) распознавать константу ALREADY_HANDLED eventlet в дополнение к своей собственной и обрабатывать ее таким же образом. Я думаю, это решит эту проблему.

Замечательно, если вы сможете исправить эту проблему. Я использую flask-socketio & gunicorn на своем производстве и не хочу терять данные.

У меня похожие проблемы, и мне было интересно, есть ли какие-нибудь новости по этому поводу?

@benoitc - Как вы думаете, предложение, сделанное @miguelgrinberg выше (позволить Gunicorn распознавать константу ALREADY_HANDLED eventlet в дополнение к своей собственной и обрабатывать ее таким же образом), является хорошей идеей?

@ kramer65, если вы можете найти способ чисто добавить поддержку для этого, я думаю, что обработчик событий имеет смысл справиться с этим.

Прямо сейчас логика для обработки этого немного скрыта внутри gunicorn.workers.async.AsyncWorker#handle_request но, возможно, это можно было бы обработать с помощью косвенного обращения через статическое свойство, которое может переопределить рабочий eventlet, или путем вызова метода экземпляра для проверки уже обработанного любым рабочим- конкретная логика, которая может существовать, при этом базовый класс работает так же, как сейчас.

@tilgovi - Прошло много времени с тех пор, как вы отправили мне свое сообщение, но я все-таки хотел на это ответить. Проблема в том, что я как бы достиг своего предела в том, что могу для этого сделать. Я действительно понятия не имею, как действовать, чтобы решить эту проблему.

Тем временем мои журналы заполнены сообщениями об ошибках, подобными приведенному ниже, так что у меня есть все основания приложить немного усилий для решения этой проблемы. Я просто не совсем понимаю, какова точная причина проблемы, не говоря уже о том, что я понимаю, как я могу ее решить.

Если кто-нибудь захочет войти в контакт, я буду рад обсудить этот вопрос, и тогда я смогу оказать немного больше помощи, чем сейчас.

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 - К сожалению, я этого не сделал. Мои журналы все еще заполняются ошибками. :-(

Кто-нибудь еще?

@ kramer65 Понятно . Я ждал этого целую вечность, если у кого-то есть исправление, поделитесь с нами! Благодарность!

любые обновления?

Я уверен, что есть более чистые способы исправить это, но, по крайней мере, это начало.

@stefaang спасибо, я попробую подумал!

Когда будет выпущено исправление для PyPI?

завтра
Пт, 17 февраля 2017 г., в 16:46, Эдди [email protected] написал:

Когда будет выпущено исправление для PyPI?

-
Вы получаете это, потому что изменили состояние открытия / закрытия.

Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/benoitc/gunicorn/issues/1210#issuecomment-280685264 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAA4ogTRMF7EfR25G6gLrktOdh_iA4Ciks5rdcDYgaJpZM4HbcdP
.

Он был выпущен?

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

Нет :(

@benoitc есть какие-нибудь слова об обновлении, которое отправляется на pypi?

@defionscode я сделаю релиз в четверг утром (завтра).

Отлично спасибо
В среду, 22 февраля 2017 г., в 11:54 Бенуа Шено [email protected]
написал:

@defionscode https://github.com/defionscode я сделаю релиз в
в четверг утром (завтра).

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/benoitc/gunicorn/issues/1210#issuecomment-281729992 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AEcrYp6QfVpWXhG14f4M-lPDHMn0cFncks5rfGhWgaJpZM4HbcdP
.

Это исправление было выпущено?

Статус @ Decker108 отслеживается https://github.com/benoitc/gunicorn/issues/1471 . Он выйдет сегодня ...

Эта ошибка все еще возникает на моей стороне с последней версией 19 и 20 Gunicorn. Это должно было быть исправлено @benoitc ?