[Web-SIG] (proto) request object spec

Ian Bicking 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 mailing list