[Web-SIG] Returned application object and fileno.
Phillip J. Eby
pje at telecommunity.com
Wed Sep 1 15:17:13 CEST 2004
At 01:39 PM 9/1/04 +0100, Alan Kennedy wrote:
>>>Hmm, I'm not sure I understand what you are saying here Andrew. The
>>>use-case we're trying to cover is where the application wants to return
>>>a file-like object to the WSGI server/framework. The applications
>>>intention should be that the contents of the file-like object, from the
>>>current file-pointer onwards, should be transferred to the return socket
>>>for the HTTP request.
>>The intent, I think, is to special-case the sending of static files,
>>allowing a server to use the most efficient method of transferring data
>>from a file to a socket that the platform provides.
>Agreed that special-casing static files for performance reasons is a good
>But we also need to consider what happens when the application returns,
>for example, a StringIO.StringIO, or a gzip.GzipFile.
No, we don't. WSGI does not support that. You must return an
*iterable*. As Andrew says, 'fileno()' was added to allow special-casing
operating system file descriptors on platforms that have them, and have
APIs like 'sendfile()' that can copy data directly from one descriptor to
If you would like to support special Java stuff, or CLR stuff, you can
always have your server look for some other attribute name and support that
as a platform-specific, optional extension for higher performance.
But that's *all* the 'fileno()' support is: a *platform-specific* *optional
extension* to boost performance in certain cases. The server isn't even
required to *check* for a fileno attribute, and the application certainly
isn't required to provide it.
The application is required to return an iterable. That's the
protocol. You want to return a "file-like" object, you *must* wrap it in
an iterable of some kind. For example:
is a perfectly reasonable way to return a StringIO.
More information about the Web-SIG