Werkzeug: Suposición incorrecta en werkzeug.serving sobre el comportamiento del socket

Creado en 1 may. 2016  ·  6Comentarios  ·  Fuente: pallets/werkzeug

Como todos sabemos, socket.send() no garantiza que todos los datos se envíen

y esta línea:
https://github.com/pallets/werkzeug/blob/03faf0569861e9d8c8c94785ad5560f735ba72da/werkzeug/serving.py#L165
combinado con gevent y la mejor tecnología de escala web, conocida como docker, me ha llevado a ese comportamiento con respuestas truncadas: 3

Parece que el socket.SocketIO debería preocuparse por eso, pero no lo hace

Comentario más útil

Experimenté este error en Python 3.5, pero solo cuando configuraba el socket subyacente en modo sin bloqueo (por ejemplo, con settimeout ). Resulta que, de hecho, esto se debe a un error ascendente en Python 3: problema 24291 . El problema se solucionó en Python 3.6 (consulte el problema 26721 )

Una solución alternativa que se ha implementado en otros servidores web es envolver el wfile en un io.BufferedWriter (por ejemplo, en wsgiref de CPython en 3.5 ) o cambiar el wbufsize para habilitar el almacenamiento en búfer por predeterminado (por ejemplo, vea este problema de gevent )

No estoy seguro de si werkzeug también quiere implementar una solución alternativa o si lo considera un problema que no es de werkzeug.

Todos 6 comentarios

Si bien probablemente tenga razón (no ha investigado nada), tenga en cuenta que el servidor de Werkzeug solo está destinado al desarrollo. Ejecutarlo en Docker y con gevent me lleva a creer que no lo usa para ese propósito.

De hecho, he estado usando docker para el desarrollo y parte del código usó gevent monkeypatches de manera bastante frívola.
Probablemente ni siquiera lo notaría si no se rompiera no entres en pánico :3

Experimenté este error en Python 3.5, pero solo cuando configuraba el socket subyacente en modo sin bloqueo (por ejemplo, con settimeout ). Resulta que, de hecho, esto se debe a un error ascendente en Python 3: problema 24291 . El problema se solucionó en Python 3.6 (consulte el problema 26721 )

Una solución alternativa que se ha implementado en otros servidores web es envolver el wfile en un io.BufferedWriter (por ejemplo, en wsgiref de CPython en 3.5 ) o cambiar el wbufsize para habilitar el almacenamiento en búfer por predeterminado (por ejemplo, vea este problema de gevent )

No estoy seguro de si werkzeug también quiere implementar una solución alternativa o si lo considera un problema que no es de werkzeug.

según la información proporcionada, creo que esto es un error de gevent o un error de stdlib, werkzeug usa escribir + vaciar en un supuesto archivo almacenado en búfer, que a su vez siempre debería funcionar, ahora me pregunto si esto también sucede en python simple, o solo en gevent

@RonnyPfannschmidt sí, lo obtengo sin gevent también, solo necesito usar un zócalo sin bloqueo en combinación con WSGIRequestHandler de werkzeug. Gevent fue solo otro ejemplo de los muchos proyectos que se ven afectados indirectamente por el error ascendente en Python 3.5 :-)

Dadas las circunstancias en las que esto sucede, así como el hecho de que está arreglado en Python 3.5 (3.4 llega a EOL en marzo), estoy cerrando esto.

¿Fue útil esta página
0 / 5 - 0 calificaciones