[Web-SIG] (proto) request object spec
ianb at colorstudy.com
Tue Nov 14 04:26:43 CET 2006
L. C. Rees wrote:
>> 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.
Hrm... but this is neither that friendly to work with, nor very reliable
(e.g., if the keys aren't there), nor particularly good WSGI practice
when it includes the response.
> A few examples are:
> wsgiorg.parsed_cookie - The contents of 'HTTP_COOKIE' stored in a
> Cookie.SimpleCookie instance
This would be possible. Phillip notes the problem of systems that
rewrite the request; this can be alleviated by putting in (SimpleCookie,
HTTP_COOKIE) so that you can check your cache. This is what I do in
paste.request.get_cookies (storing the value in paste.cookies). Note,
though, that you should never check this value directly, you should only
use a function that will calculate the value when necessary.
It almost makes me think something like this should be named
paste._cookies, to discourage direct access.
In this particular case, while a standard key for the cached value would
be nice, the overhead of double-parsing the cookies is so low that it's
not too big a deal. My (now withdrawn) suggestion of wsgiorg.form_vars
was driven by this same need, but again with a function setting the
value as needed.
> wsgiorg.start_request - The start_request function
> wsgiorg.headers - the headers list
> wsgiorg.status - the response status string
Erk. I think it's best to keep request and response separate. At least
if you are using WSGI as the foundation for your system, WSGI does keep
them separate. It is better for intermediaries; otherwise they'd have
to rewrite the environment. Which isn't hard, but you already have to
switch things around in the function call, having two switches is just
asking for trouble.
> wsgiorg.application_uri - the base request URI string, equivalent to
> the output of wsgiref.util.application_uri
This is puts redundant and potentially out of sync information in the
environment. This is best done as a property on the request object that
calculates application_uri from its base components. In this case the
construction is fast enough that caching it isn't worth it.
> wsgiorg.request_uri - the full request URI including the query string,
> equivalent to the default output of wsgiref.util.request_uri
Ditto this; great as a property on a request object, not so great as a key.
> 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
I know in my own code I avoid assuming any particular context for the
code. I think this is generally best, and makes things easier to test
and deploy in different layerings.
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Web-SIG