Comme nous le savons tous, socket.send() ne garantit pas l'envoi de toutes les données
et cette ligne :
https://github.com/pallets/werkzeug/blob/03faf0569861e9d8c8c94785ad5560f735ba72da/werkzeug/serving.py#L165
combiné avec gevent et la plus grande technologie Webscale, connue sous le nom de docker, m'a conduit à ce comportement avec des réponses tronquées : 3
Il semble que le socket.SocketIO devrait s'en soucier, mais ce n'est pas le cas
Bien que vous ayez probablement raison (vous n'avez fait aucune recherche), veuillez noter que le serveur de Werkzeug est uniquement destiné au développement. L'exécuter dans Docker et avec gevent me porte à croire que vous ne l'utilisez pas à cette fin.
J'ai utilisé docker pour le développement et une partie du code a utilisé gevent monkeypatches de manière assez frivole.
Je ne le remarquerais probablement même pas si ça ne cassait pas la panique :3
J'ai rencontré ce bogue dans Python 3.5, mais uniquement lors de la définition du socket sous-jacent en mode non bloquant (par exemple avec settimeout
). Il s'avère que cela est en fait causé par un bogue en amont dans Python 3 : issue24291 . Le problème est résolu dans Python 3.6 (voir issue26721 )
Une solution de contournement qui a été implémentée dans d'autres serveurs Web consiste à encapsuler le wfile
dans un io.BufferedWriter
(par exemple, dans le wsgiref de CPython en 3.5 ) ou à modifier le wbufsize
pour activer la mise en mémoire tampon par par défaut (par exemple, voir this gevent issue )
Je ne sais pas si werkzeug souhaite également implémenter une solution de contournement ou considère qu'il s'agit d'un problème non lié à werkzeug.
sur la base des informations fournies, je pense qu'il s'agit en effet soit d'un bogue gevent, soit d'un bogue stdlib, werkzeug utilise write + flush sur un fichier tampon supposé, qui à son tour devrait toujours fonctionner, maintenant je me demande si cela se produit également sur plain python, ou seulement sur gevent
@RonnyPfannschmidt oui, je l'obtiens sans gevent
aussi, j'ai juste besoin d'utiliser un socket non bloquant en combinaison avec le WSGIRequestHandler
de werkzeug. Gevent n'était qu'un autre exemple des nombreux projets qui sont indirectement affectés par le bogue en amont de Python 3.5 :-)
Compte tenu des circonstances dans lesquelles cela se produit, ainsi que du fait qu'il est corrigé dans Python 3.5 (3.4 passe en fin de vie en mars), je ferme ceci.
Commentaire le plus utile
J'ai rencontré ce bogue dans Python 3.5, mais uniquement lors de la définition du socket sous-jacent en mode non bloquant (par exemple avec
settimeout
). Il s'avère que cela est en fait causé par un bogue en amont dans Python 3 : issue24291 . Le problème est résolu dans Python 3.6 (voir issue26721 )Une solution de contournement qui a été implémentée dans d'autres serveurs Web consiste à encapsuler le
wfile
dans unio.BufferedWriter
(par exemple, dans le wsgiref de CPython en 3.5 ) ou à modifier lewbufsize
pour activer la mise en mémoire tampon par par défaut (par exemple, voir this gevent issue )Je ne sais pas si werkzeug souhaite également implémenter une solution de contournement ou considère qu'il s'agit d'un problème non lié à werkzeug.