[Web-SIG] serving (potentially large) files through wsgi?

[Ian Bicking]

Manlio Perillo wrote:
> Phillip J. Eby ha scritto:
>> At 09:06 PM 12/17/2007 +0100, Manlio Perillo wrote:
>>> Phillip J. Eby ha scritto:
>>>> This is precisely why WSGI doesn't really have any "configuration" 
>>>> defined, because the whole idea is that it should be as 
>>>> "plug-and-play" as possible.  Server-level configuration options are 
>>>> a liability to be avoided, a sometimes-necessary evil.  They aren't 
>>>> a feature.
>>>
>>> Disagree.
>>
>> Note that your disagreement doesn't retroactively change WSGI's design 
>> goals or rationale, 
> 
> 
> I disagree with your "Server-level configuration options are a liability 
> to be avoided, a sometimes-necessary evil" phrase.
> 
> But now I'm not sure of what do you mean by "configuration".

I think there might still be some confusion about configuration.  I'll 
offer my take:

There's generally two valid kinds of configuration -- the server's 
configuration (host, port, ssl, etc), and the application configuration 
(database connection parameters, maybe some theming options, etc).

Obviously server configuration goes in Nginx.

If you put both of these in Nginx, I think that's fine.  That is, if you 
allow people to create WSGI applications through Nginx, providing 
information to the application like database connection information, 
then that's totally fine.  There's no standard WSGI way to do that; the 
only thing approaching a standard for that is Paste Deploy's interfaces 
(which I'm sure would be possible to support in Nginx -- they are 
interfaces, not an implementation: 
http://pythonpaste.org/deploy/#defining-factories).

Another kind of "configuration" is configuring the application 
implementation with respect to its framework.  This is where you might 
choose your template language, or a default charset/encoding.  This is 
where you might choose whether to let the framework handle range 
requests.  This is not actually configuration in my opinion, but it is 
frequently called configuration.  I think it's simply "programming".  It 
has nothing to do with WSGI, and must be fully encapsulated in a WSGI 
application.  People deploying the application should not encounter any 
of these options.

The range stuff apparently is not really an issue of this, as Nginx is 
acting reasonably and obeying the restrictions of HTTP, which in turn 
satisfies WSGI.  If Nginx was rewriting partial responses to be... 
doubly partial or something like that, that would really just be a bug. 
  These kinds of bugs exist and are sometimes excused as being 
"configuration".  But when one configuration setting is valid and 
another is simply invalid, the bug is having that configuration setting 
at all.  But at least this case doesn't seem to be an issue; hopefully 
other issues that might be similar will be resolved in Nginx.  You 
should never have to have Nginx-specific notes about deploying a WSGI 
application (except perhaps if you want to provide helpful notes about 
how to supply the real configuration in an Nginx configuration file).

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org