[Web-SIG] serving (potentially large) files through wsgi?
Ian Bicking
ianb at colorstudy.com
Wed Dec 19 00:21:22 CET 2007
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
More information about the Web-SIG
mailing list