Specifications related to WSGI¶
This page holds specifications (proposed, accepted, and withdrawn) that build on WSGI.
About these specifications¶
These specifications are written up here and discussed on WEB-SIG. Once
accepted, these can all use the wsgiorg.
prefix for their keys.
Until accepted, please use x-wsgiorg.
– this is primarily so that
people who implement the specification before it is accepted will not
leave out-of-spec implementations around (except the obvious ones due
to the x-
).
To be “accepted” the proposal should have certain qualities:
The spec won’t change without good reason, so you can start implementing against it (once it is “approved”).
It’s useful in multiple contexts; if one implementation is all anyone will ever need, then just make your implementation. Feel free to discuss it, but you don’t need anyone’s approval.
Some eyes have been on it, and it’s been reviewed by multiple people.
There are certain advantages:
Having implemented either side, you can expect that maybe someone will care (either producing or consuming what you are looking for).
Someone won’t implement something they think is the same, but isn’t, because the document specifies the requirements sufficiently.
New proposals will take old proposals into account, and so they shouldn’t overlap or repeat their purposes.
There’s no particular process for a proposal to become accepted. Someone else should like your proposal (+1, not just +0), and probably no one should be opposed (no -1’s).
Unless noted otherwise, everything here can be assumed to be public domain (in keeping with the purpose of posting material here).
Accepted¶
Proposed¶
Withdrawn¶
Wanted¶
These don’t exist yet, but they could. Write one?
A standard place to put HTTP proxy scheme and host information (e.g., when a server acts as an HTTP proxy the request looks like
GET http://hostname.org/path ...
, and we don’t have a place to keephttp://hostname.org
).Ben Bangert suggested a simple session standard, focused solely on the session ID (persistence handled elsewhere). This is fairly modest but still useful. This was in an email: http://mail.python.org/pipermail/web-sig/2006-January/001858.html
Maybe a full session interface built on the session ID standard. This is an API proposed earlier: http://svn.colorstudy.com/home/ianb/proposed_session_interface.py
Often debugging tools open security holes (for example,
paste.evalexception
gives you a Python prompt on every exception). Authentication isn’t really the right way to handle it, because debugging might involve logging in as various users. A specification could just define a key that indicates when these debugging tools should be allowed. This might get set by configuration, IP address, a cookie, etc.Debugging mode is something that can be used in all sorts of places; to increase verbosity, annotate output pages, displaying errors in the browser, etc. Having a single key for turning on debugging mode would allow its consumption in lots of places. Not as strict as authenticating.
Some systems prefer that unexpected exceptions bubble up, like test frameworks. A key could define this case (modelled on
paste.throw_errors
) and thus disable exception catchers.Logging is a tricky situation. The
logging
module allows for statically setting up logging systems, then configuring them at startup. This often isn’t the best way to set up logging. Putting alogging.Logger
instance right in the environment might be better. This requires some design and usage before setting on one spec.Request object wrapping the environment.
Thread-local values are a common technique in web frameworks, allowing global objects or functions to return request-specific information. This pattern could be codified into one core system, using some feedback from existing systems (which have their advantages and flaws).
Configuration takes fairly common forms, usually a dict of some sort. It could be put somewhere standard.
Maybe Paste Deploy’s entry points could be standardized. (Paste Deploy itself only consumes those entry points; other consumers are possible and packages implementing those entry points don’t introduce any dependency on Paste Deploy)
A way to extend
wsgiref.validate
to add more validation, for all these new specs. (Probably this is an implementation, not a spec)A way to describe custom keys, maybe associated with the validation.
Anchors for doing recursive calls, similar to
paste.recursive
. (it’s kind of an old module that is more complicated than it needs to be)A place to put a database transaction manager
More user-based information than just
REMOTE_USER
; likewsgiorg.user_info
? The basics of this are described in A very basic description of authentication opportunities in WSGI, but it doesn’t cover anything advanced.
These can be written based on WSGI Enhancement Proposal template.