Werkzeug: Falsche Annahme in werkzeug.serving über Socket-Verhalten

Obwohl Sie wahrscheinlich Recht haben (habe keine Nachforschungen angestellt), beachten Sie bitte, dass der Server von Werkzeug nur für die Entwicklung vorgesehen ist. Das Ausführen in Docker und mit gevent lässt mich glauben, dass Sie es nicht für diesen Zweck verwenden.

Ich habe tatsächlich Docker für die Entwicklung verwendet und ein Teil des Codes hat ziemlich leichtfertig Affenpatches verwendet.
Ich würde es wahrscheinlich nicht einmal bemerken, wenn es dontpanic nicht brechen würde :3

Ich habe diesen Fehler in Python 3.5 erlebt, aber nur, wenn der zugrunde liegende Socket in den nicht blockierenden Modus versetzt wurde (z. B. mit settimeout ). Es stellt sich heraus, dass dies tatsächlich durch einen Upstream-Fehler in Python 3 verursacht wird: issue24291 . Das Problem wurde in Python 3.6 behoben (siehe issue26721 )

Eine Problemumgehung, die in anderen Webservern implementiert wurde, besteht darin, wfile in io.BufferedWriter einzuschließen (z. B. in CPythons wsgiref in 3.5 ) oder wbufsize zu ändern, um die Pufferung zu aktivieren default (siehe z. B. diese Ausgabe von gevent )

Ich bin mir nicht sicher, ob werkzeug auch eine Problemumgehung implementieren möchte oder es als Nicht-Werkzeug-Problem betrachtet.

Basierend auf den bereitgestellten Informationen glaube ich, dass dies in der Tat entweder ein Gevent-Fehler oder ein stdlib-Fehler ist. Werkzeug verwendet Write + Flush für eine vermeintliche gepufferte Datei, was wiederum immer funktionieren sollte auf gevent

@RonnyPfannschmidt ja, ich bekomme es auch ohne gevent , ich muss nur einen nicht blockierenden Socket in Kombination mit WSGIRequestHandler von werkzeug verwenden. Gevent war nur ein weiteres Beispiel für die vielen Projekte, die indirekt von dem Upstream-Bug in Python 3.5 betroffen sind :-)

Angesichts der Umstände, unter denen dies passiert, sowie der Tatsache, dass es in Python 3.5 behoben ist (3.4 geht im März EOL), schließe ich dies.