[Web-SIG] (proto) request object spec

[L. C. Rees]

> 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