Meinheld provides a wsgi.file_wrapper, however, it seems that the provided implementation does not conform to PEP 3333 (see the relevant chapter: Optional Platform-Specific File Handling).
If the provided file-like object implements .read(), but not .fileno(), Meinheld raises a TypeError, and disconnects the client.
This seems to happen because PyObject_AsFileDescriptor() is used here indiscriminately, even if the provided file-like object doesn't have one:
|
in_fd = PyObject_AsFileDescriptor(filelike); |
The specification reads:
Of course, platform-specific file transmission APIs don't usually accept arbitrary "file-like" objects. Therefore, a wsgi.file_wrapper has to introspect the supplied object for things such as a fileno() (Unix-like OSes) or a java.nio.FileChannel (under Jython) in order to determine if the file-like object is suitable for use with the platform-specific API it supports.
Note that even if the object is not suitable for the platform API, the wsgi.file_wrapper must still return an iterable that wraps read() and close(), so that applications using file wrappers are portable across platforms.
Meinheld provides a
wsgi.file_wrapper, however, it seems that the provided implementation does not conform to PEP 3333 (see the relevant chapter: Optional Platform-Specific File Handling).If the provided file-like object implements
.read(), but not.fileno(), Meinheld raises aTypeError, and disconnects the client.This seems to happen because
PyObject_AsFileDescriptor()is used here indiscriminately, even if the provided file-like object doesn't have one:meinheld/meinheld/server/response.c
Line 1267 in 6ddb22b
The specification reads: