Gunicorn: L'objet 'Response' n'a pas d'attribut 'status_code' dans wsgi.py avec websockets

@bclark8923 avez-vous une application qui pourrait aider à reproduire le problème ?

Ouais! Qu'est-ce que tu aimerais que je fasse?

Le lundi 28 mars 2016, Benoit Chesneau [email protected] a écrit :

@bclark8923 https://github.com/bclark8923 avez-vous une application
cela pourrait aider à reproduire le problème?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/benoitc/gunicorn/issues/1210#issuecomment -202484667

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

Apprenez à me connaître sur Facebook https://facebook.com/bclark8923 & Twitter
https://twitter.com/blaurenceclark !

@ bclark8923 s'il peut être diffusé, je pourrais éventuellement inclure une partie dans un test qui aiderait :)

Quelle version de gunicorn utilisez-vous également ?

Oui s'il vous plaît! Envoyez-moi un e-mail [email protected] et 19.x de quelque sorte peut vérifier
bientôt

Le lundi 28 mars 2016, Benoit Chesneau [email protected] a écrit :

@bclark8923 https://github.com/bclark8923 s'il peut être diffusé ainsi
éventuellement, je pourrais inclure une partie dans un test qui aiderait :)

Quelle version de gunicorn utilisez-vous également ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/benoitc/gunicorn/issues/1210#issuecomment -202492005

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

Apprenez à me connaître sur Facebook https://facebook.com/bclark8923 & Twitter
https://twitter.com/blaurenceclark !

Utilisation de la version 19.4.5

J'ai le même problème. J'utilise gunicorn version 18.0.

Un correctif déjà disponible ?

si quelqu'un a du code z pour le reproduire, cela aiderait :)

@benoitc - Cela a du sens .. ;-)

Je vais arranger quelque chose la semaine prochaine et je vous tiens au courant !

@benoitc - D' arrangé quelque chose avant le week-end après tout.

Vous pouvez trouver le repo avec des instructions dans le fichier readme ici : https://github.com/kramer65/gunicorn-error

btw: j'utilise la version 18.0 de gunicorn

Quelque chose doit probablement renvoyer gunicorn.workers.async.ALREADY_HANDLED ou gunicorn essaiera de consigner la demande dès que l'application reviendra de son gestionnaire WSGI. Gunicorn a besoin de savoir, à la place, que la demande est désormais entièrement gérée par l'application.

Les deux exemples du répertoire "examples/websocket" renvoient cette constante à partir de leur gestionnaire WSGI.

@benoitc - L'exemple pour reproduire l'erreur vous aide-t-il à trouver l'erreur ? Puis-je être d'une autre aide pour aider à résoudre ce problème?

@kramer65 oui j'ai reproduit l'erreur.

Ainsi, Gunicorn est un moteur WSGI pur et attend une réponse WSGI contenant un statut :
https://github.com/benoitc/gunicorn/blob/master/gunicorn/http/wsgi.py#L242

(lié à ce code : https://github.com/benoitc/gunicorn/blob/master/gunicorn/workers/async.py#L103-L119)

Comme @tilgovi l'a dit, vous pouvez contourner la gestion des réponses de gunicorn en retournant ALREADY_HANDLED

Pour autant que j'ai lu le code de flash socketio, il encapsule l'application flask dans socketio.Middleware qui hérite lui-même de engineio.middleware.Middleware :
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/middleware.py

qui renvoient l'application wsgi ou leur propre gestionnaire s'il trouve le chemin :
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/middleware.py#L45 -L52

Il renvoie donc socketio.Server.handle_request sur le chemin websocket :
https://github.com/miguelgrinberg/Flask-SocketIO/blob/master/flask_socketio/__init__.py#L144

qui lui-même renvoie engineio.Server.handle_request (beaucoup de deps circulaires dans ce projet...) :
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/server.py#L184

À ce stade, il semble que ni socket.handle_get_request ni socket. handle_post_request n'aient défini le statut :
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/socket.py#L69 -L96

Et puis une erreur peut se produire ici :
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/server.py#L251 -L252

car il peut renvoyer une réponse sans avoir défini de statut ou quoi que ce soit. Je peux voir que la mise à niveau utilise le même objet websocket que dans notre exemple :
https://github.com/benoitc/gunicorn/blob/master/examples/websocket/websocket.py

Je pense qu'au lieu de renvoyer le r final ici :
https://github.com/miguelgrinberg/python-engineio/blob/master/engineio/server.py#L251 -L252

Il devrait probablement retourner ALREADY_HANDLED comme ici :
https://github.com/benoitc/gunicorn/blob/master/examples/websocket/websocket.py#L115

Juste une supposition de toute façon car ce code est assez difficile à lire. Espérons que cela aidera.

@kramer65, informez-moi quand même de l'état de ce ticket pour vous :)

@benoitc la ALREADY_HANDLED est spécifique à gunicorn. Eventlet a sa propre version de cette constante, définie de manière différente : https://github.com/eventlet/eventlet/blob/2cd5f1d9aea53efb4526e7185017bdcc84732588/eventlet/wsgi.py#L69.

La r que vous avez suivie dans le code renvoie le ALREADY_HANDLED evenlet lorsque la connexion websocket se termine. Ceci est géré automatiquement par eventlet : https://github.com/eventlet/eventlet/blob/2cd5f1d9aea53efb4526e7185017bdcc84732588/eventlet/websocket.py#L135.

Gunicorn devrait (je pense) reconnaître la constante ALREADY_HANDLED eventlet en plus de la sienne et la gérer de la même manière. Je pense que cela résoudra ce problème.

C'est super si vous pouvez résoudre ce problème. J'exécute flask-socketio & gunicorn sur ma production et je ne veux pas perdre de données.

Je rencontre des problèmes similaires et je me demandais s'il y avait des nouvelles à ce sujet?

@benoitc - Pensez-vous que la suggestion faite par @miguelgrinberg ci-dessus (pour laisser Gunicorn reconnaître la constante ALREADY_HANDLED de l'événementlet en plus de la sienne et la gérer de la même manière) est une bonne idée ?

@ kramer65 si vous pouvez trouver un moyen d'ajouter proprement le support pour cela, je pense qu'il est logique que le travailleur eventlet le gère.

À l'heure actuelle, la logique pour gérer cela est un peu enfouie dans gunicorn.workers.async.AsyncWorker#handle_request mais cela pourrait peut-être être géré avec une indirection via une propriété statique que le travailleur de l'événementlet peut remplacer, ou en appelant une méthode d'instance pour vérifier déjà gérée par n'importe quel travailleur- logique spécifique qui pourrait exister, avec la classe de base faisant comme elle le fait maintenant.

@tilgovi - Cela fait un moment que vous ne m'avez pas envoyé votre message, mais je voulais répondre à cela après tout. Le problème est que j'ai un peu atteint ma limite dans ce que je peux faire pour cela. Je n'ai vraiment aucune idée de comment procéder pour résoudre ce problème.

En attendant, mes journaux sont remplis de messages d'erreur comme celui ci-dessous, j'ai donc toutes les raisons de consacrer de l'énergie à la résolution de ce problème. Je ne comprends tout simplement pas complètement quelle est la cause exacte du problème, encore moins que je comprends comment je pourrais résoudre ce problème.

Si quelqu'un veut entrer en contact, je serais heureux de discuter de la question, et alors je pourrais peut-être être un peu plus utile que je ne le suis actuellement.

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'

l'a-t-on réparé ?.....

@qwexvf - Malheureusement, je ne l'ai pas fait. Mes journaux se remplissent toujours d'erreurs. :-(

Quelqu'un d'autre?

@kramer65 je vois. J'attends cela depuis des lustres, si quelqu'un a le correctif, partagez-le avec nous ! Merci!

les mises à jour?

Je suis sûr qu'il existe des moyens plus propres de résoudre ce problème, mais au moins c'est un début.

@stefaang merci, je vais essayer d'y penser !

Quand le correctif sera-t-il publié sur PyPI ?

demain
Le vendredi 17 février 2017 à 16h46, Eddie [email protected] a écrit :

Quand le correctif sera-t-il publié sur PyPI ?

-
Vous recevez ceci parce que vous avez modifié l'état ouvert/fermé.

Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/benoitc/gunicorn/issues/1210#issuecomment-280685264 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAA4ogTRMF7EfR25G6gLrktOdh_iA4Ciks5rdcDYgaJpZM4HbcdP
.

A-t-il été publié ?

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

Non :(

@benoitc un mot sur la mise à jour poussée vers pypi?

@defionscode je ferai une sortie jeudi matin (demain).

Excellent merci
Le mer. 22 février 2017 à 11h54 Benoit Chesneau [email protected]
a écrit:

@defionscode https://github.com/defionscode je ferai une sortie dans le
jeudi matin (demain).

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/benoitc/gunicorn/issues/1210#issuecomment-281729992 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AEcrYp6QfVpWXhG14f4M-lPDHMn0cFncks5rfGhWgaJpZM4HbcdP
.

Ce correctif a-t-il été publié ?

Le statut de https://github.com/benoitc/gunicorn/issues/1471 . Il sortira aujourd'hui...

Ce bug se produit toujours de mon côté avec les dernières versions 19 et 20 de gunicorn. C'était censé être corrigé @benoitc ?