[Web-SIG] Questions/suggestions on 'wsgi.file_wrapper'
Phillip J. Eby
pje at telecommunity.com
Wed Dec 21 18:41:39 CET 2005
At 11:25 AM 12/21/2005 -0500, Jim Fulton wrote:
>Here are some questions and sugesstions on the 'wsgi.file_wrapper'
>part of the WSGI API:
>1. Does this need to be optional? It seems that it would be
> easy for any server to provide this, it would be nice for
> applications to be able to rely in it.
It's intentionally optional because its presence signifies that the server
can do things *better* than the application, if and only if the object is a
"real" operating system file or other "special" object. The only reason
the spec requires only a "file-like" object rather than an object with a
valid "fileno()" method, is because somebody wanted to support Jython
objects wrapping Java sio(?) objects, for a Java equivalent of sendfile().
>2. If the file-like object passed has a close method, wouldn't
> it be acceptable for the iterator returned by wsgi.file_wrapper
> to close it when iteration is done?
> I would slightly prefer:
> "It may have a close() method, and if so, the iterable returned by
> wsgi.file_wrapper must have a close() method that invokes the original
> file-like object's close() method, or the iterable must close the file
> when the file-like object's read method returns no data."
> I prefer this because it allows a simple generator implementation of
> a default wsgi.file_wrapper.
I'm sorry, I don't understand what you're asking for here. I think maybe
you have a misunderstanding about why the spec is arranged the way it is
here. It is intended to ensure that any middleware between the server and
the application will be able to treat the wrapper as a valid WSGI
application return value. The server is allowed to strip off the wrapper,
if that's in fact what it receives. But the wrapper has to be a 100% valid
WSGI return value, or middleware will get confused. The server must also
only do special handling *if* it receives the wrapper as a return value; it
can't assume that just because you called file_wrapper() that it is going
to use that handler.
If I understand your suggestion correctly, you're asking to change that in
a way that disallows early closing, and I don't think that should be
allowed. If the file has a close(), any middleware involved needs to be
allowed to call it.
>3. The server should be allowed to use the file wrapper in a different
> thread than the one used to run the application. This should be noted.
> Applications should not return file-like objects that rely on running
> in the same thread. This too should be noted.
This seems reasonable to me. For the actual use cases file_wrapper was
intended to support (sendfile() and the Java equivalent thereof) this
should be no problem at all.
More information about the Web-SIG