[Web-SIG] Other kinds of environment variables

[Ian Bicking]

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 
these.

> 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 
information.

> * 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 
same key.

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