> That is my point. There are many smallish reasons to > prefer one request convenience interface to another. Why > try to sanctify some particular preferences? We don't > need it for interop because WSGI already gives us that.
A not infrequent WSGI pattern is putting all of the various WSGI components in a request dictionary or even 'environ' itself and passing that to other WSGI applications. The dictionary, in effect, is used as a lightweight request object. In light of this pattern, an intermediate step between no request object standard and an overly standard might be agreement on standard environment keys common to most WSGI request objects. These keys could then be used in 'environ', a request dictionary, or by wrapping them in a request object. A few examples are: wsgiorg.parsed_cookie - The contents of 'HTTP_COOKIE' stored in a Cookie.SimpleCookie instance wsgiorg.start_request - The start_request function wsgiorg.headers - the headers list wsgiorg.status - the response status string wsgiorg.application_uri - the base request URI string, equivalent to the output of wsgiref.util.application_uri wsgiorg.request_uri - the full request URI including the query string, equivalent to the default output of wsgiref.util.request_uri Operations that produce entries such as these are frequently performed by middleware. Standard keys would provide a way for the operation to be performed once and the results of the operation to be stored and passed along to other WSGI software in a predictable way-lcr _______________________________________________ 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
