[Web-SIG] Other kinds of environment variables
ianb at colorstudy.com
Fri Aug 27 02:03:36 CEST 2004
Mark Nottingham wrote:
> One thing that seems to be missing in WSGI to me is the communication of
> the delineation between what the server does and what the application does.
> The latest drafts says;
> In general, the server or gateway is responsible for ensuring that
> correct headers are sent to the client: if an application omits a needed
> header, the server or gateway *shoud* add it. [...] If the application
> supplies a header that the server would ordinarily supply, or that
> contradicts the server's intended behaviour [...] the server or gateway
> *may* discard the conflicting header, provided that its action is
> recorded for the benefit of the application author.
> I'm a bit uncomfortable with this, because there's no standard way for
> the action to be "recorded for the benefit of the application author."
> IMO this is one of the major problems with CGI.
The closest thing to a standard would be, I think,
environ['wsgi.error']. I would expect to see errors about the
application to be sent there. I also think it's reasonable not to
specify it further than this -- many error logging facilities are
possible, and it's all very server-specific.
> In other words, there's a laundry list of HTTP features that may or may
> not be handled by the server on behalf of the application, depending on
> how it's written and configured. Giving the application some idea of
> what it can expect the server to do, and how it will do it, would help
> application frameworks decide what tasks it needs to take on itself.
But then this is a different issue. I think Phillip likes the idea of
"configuration" for this. I give it scare quotes because I think
Phillip thinks about configuration somewhat differently than most
people, and configuration plays a different sort of role in PEAK (and
Zope 3). It's a way of plugging pieces together, rather than just a way
of indicating installation-specific values.
But, an earlier WSGI interface didn't have wsgi.threaded or
wsgi.multiprocess, and I think it would actually be hard to work without
> For example;
> * HTTP auth - does the server make the Authentication header available?
> Automatically generate 401s when configured to require auth? If the
> application framework wishes to perform auth on its own, will it have
> the appropriate information available?
If the server does not provide the Authentication header, that would be
useful to know. Of course, sometimes you can't know that -- a CGI
script doesn't know how its parent is configured. Using Apache, you can
configure it both ways for CGI scripts (and I think they even make this
easier and more explicit in Apache 2, so you shouldn't just expect it to
always be off).
But I can appreciate the annoyance when you don't know if HTTP auth will
work, or you're new to this (or come from someplace like PHP) you just
go nuts trying to figure out why the software won't let you log in.
> * chunked encoding - does the server chunk the body when appropriate?
> * content-length - does the server automatically calculate it?
These seem useful.
> * cache validation - does the server handle If-Modified-Since and
> If-None-Match requests appropriately (e.g., with a 304)?
I would almost certainly expect this to be false. There may be some
WSGI servers that have an extended notion of the application, so they
can look at things like the modification date. But those are likely to
be uncommon -- more likely only applications will know the necessary
> * content-encoding - does the server apply content-encoding in requests
> and/or responses as appropriate, and what schemes does it support?
> * transfer-encoding - same as content-encoding
Again, seems useful. What harm would there be if you assume they don't,
or assume they do? I haven't thought this part through.
When I think of middleware, I can think of many things like this. In
most cases, I'd add a key, and if the key wasn't present I'd know it was
false. But it can be odd. Say I have a middleware that catches
exceptions, because that's my one example at the moment. If it is
present, it would be nice if other applications didn't catch exceptions,
and let them propagate all the way up. So, the application looks for
environ.get('ianb_middleware.exception_catcher')? That's weird, because
someone else comes along and makes their own exception catcher that
works like mine; what key do they use? It would be nice if we used the
But then, at this point I might suggest we use
'webapp0.exception_catcher', leading up to a Web App standard that
defines the meaning for a bunch more keys ('webapp1.exception_catcher'
once we agree on a standard).
Anyway, that's my theory on how this might go.
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG