Re: wsgi.file_wrapper
Graham Dumpleton
http://groups.google.com/group/modwsgi
See comments below.
2008/5/31 caram...@yahoo.com <caram...@yahoo.com>:
> Hi! I'm a cotnent user of mod_wsgi. I decided to try the new wsgi.file_wrapper function, but it wasn't what I expected.
> I expected it to work sort of like the DECLINE response of mod_python, so that the response
> would be handled fully by Apache, just as if it was a direct request for the file.
> That would mean dealing with content negotiation, determining whether the response could possibly be a "304 Not Modified",
> and using Apache's mod_magic to serve the correct "Content-Type" header. None of this worked with the file_wrapper.
> So I'm just eager to know, will mod_wsgi get something like mod_python's DECLINE response in the future?
> Is it somehow what's discussed in issue 14: http://code.google.com/p/modwsgi/issues/detail?id=14
> That would be better than a decline, since you wouldn't be locked to serving the url given by the client.
It doesn't work how you expect as that isn't how wsgi.file_wrapper is
defined. See WSGI specification at:
http://www.python.org/dev/peps/pep-0333/#optional-platform-specific-file-handling
Remember that WSGI is server agnostic, and thus you will never get a
WSGI specific feature which is for delegating a request back to the
underlying server as there can never be any guarantee that a
server/adapter could even implement it the same for all platforms.
Whether mod_wsgi will provide an Apache specific feature as per
discussion in that issue I don't know. General opinion of others was
to concentrate on just WSGI and not Apache specific extensions.
I still find the idea attractive, but there are some challenges with
even being able to implement it. It may only be possible to implement
it for mod_wsgi daemon mode and if that is the case one would have to
question whether it was worth doing it.
Please keep follow ups on the list.
Graham