[Web-SIG] serving (potentially large) files through wsgi?
Phillip J. Eby
pje at telecommunity.com
Wed Dec 19 18:46:27 CET 2007
At 12:12 PM 12/19/2007 +0100, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
>>At 11:51 PM 12/18/2007 +0100, Manlio Perillo wrote:
>>>Phillip J. Eby ha scritto:
>>>>At 10:10 PM 12/18/2007 +0100, Manlio Perillo wrote:
>>>>>Here I would just say that when someone install something on its
>>>>>system, it should at least know what he is doing.
>>>>And I repeat: you're welcome to your opinions about what's good
>>>>or bad, but that has nothing to do with WSGI's design rationale,
>>>>which is based on *different* goals.
>>>The problem is that I don't think that having many server
>>>configuration parameters with "safe" defaults value is against
>>>your design goals.
>>Sometimes parameters are a necessary evil; that doesn't make them
>>any less evil, just more necessary. :)
>Ok, we diverge here ;-)
>If a program does not have configuration parameters then:
>1) the program is probabily very simple
>2) the programmer thinks he gets the best values for program
> configuration, so that the user does not needs to interfere
We're not talking about "a program", we're talking about a WSGI
server. By the very nature of WSGI's goals, servers should be
interchangeable and transparent to the application. WSGI
deliberately gives applications almost complete control over the HTTP
transaction, and limits the role of a server to roughly what a HTTP
proxy is allowed to do.
Again, configuration options for the *server* that's hosting the WSGI
application are thus by definition evil -- even if sometimes
*necessary* -- since the existence of options means that the
application author(s) must be aware of these options in order to
communicate to the user/deployer what needs to be done with them.
>This is not true: what `wsgi_allow_ranges` means is:
>- by default nginx does not try to add support to partial requests, so
> this must be implemented by the WSGI application
>- if you enable this directive, then nginx will add (basic) partial
> requests support for you
A server providing options that allow for optimizing the server's
behavior for a specific type of application is a sometimes-necessary
evil. For example, an asynchronous server might by default run WSGI
applications in their own threads, but have an option to specify that
a particular application is non-blocking and thus can be run more
efficiently in the main thread.
More information about the Web-SIG