I'm thinking that we should start a less-formal spec about WSGI conventions. Here's some initial things:
* Username callback, per recent discussion * A key to suppress the catching of unexpected errors (e.g., when running in a test, you want exceptions to go all the way up) * For internal redirects, a way to indicate the previous WSGI request environment * A key for the session id, per Ben's email * Some CGIish variables. We all know REMOTE_USER (though I've seen LOGIN_USER too, IIS?). If I want to put user group information into the environment as a simple string, where would that go? I think there's other ones like this too. Some of these are just collecting current knowledge about CGI-like environments that we're likely to encounter. In each of these cases, you don't *need* to use any of these (you can make your own ad hoc techniques), or pay attention to the values that may be in the environment for these. But, barring some reason to the contrary, why not stick with convention? Basically I want to document some conventions. Particularly the simple ones. I almost think we can do this in the wiki, because it's not that formal of a process. I imagine two stages: * People talk about what they are already doing. This way people know what precedence exists at least. * We make a new namespace (or reuse 'wsgi') where things get moved after some discussion. I would prefer a namespace other than wsgi. * If we agree on something we later realize is stupid, we abandon the old key and use another one. Because these are all optional to support for now (and for the forseeable future), specific versions of a spec and whatnot don't seem necessary. Maybe people can use 'x-wsgi' (or x-whatever-we-decide) as a namespace for proposals (when accompanied by code). -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
