Werkzeug: Hypothèse incorrecte dans werkzeug.serving sur le comportement du socket

Créé le 1 mai 2016  ·  6Commentaires  ·  Source: pallets/werkzeug

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

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 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.

Tous les 6 commentaires

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.

Cette page vous a été utile?
0 / 5 - 0 notes