[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 mailing list