[Web-SIG] (proto) request object spec

[Phillip J. Eby]

At 06:36 PM 11/13/2006 -0700, L. C. Rees wrote:
>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

Do you mean start_response?  If so, what do you need it in the environ for?


>wsgiorg.headers - the headers list
>
>wsgiorg.status - the response status string

Not too bad of an idea -- except that it's only useful within the scope of 
a framework that is *not* WSGI-based, unless you are also going to have a 
start_response that works by setting them in the environ.  But even that 
isn't WSGI-compliant, because the spec explicitly allows the recipient of 
an environ to modify it in any way they like -- including clearing it 
altogether.  So, I've already rejected this idea several times over, 
because I keep thinking it's a good idea myself until I think it through 
again.  :)


>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

These two cannot be used or implemented without breaking PEP 333 
compatibility for middleware.  Don't even think about doing this.


>Operations that produce entries such as these are frequently performed by
>middleware.

This is not what middleware is for; please don't encourage people to do 
this.  Library functions are the One Obvious way to perform operations on 
environ keys.  Middleware is mainly useful for:

* logging/debugging
* response modification
* dispatching
* URL rewriting

It isn't really intended as a mechanism to stick random features into the 
environ; such features can usually be implemented as libraries and gain the 
following benefits compared to middleware:

* better overall server performance
* cleaner APIs
* easier to understand and use
* no need to configure a middleware stack


>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

This kind of caching breaks middleware stacks.  Remember, environ may be 
freely modified by middleware and applications, making the caches stale and 
invalid!  (This is why wsgiref functions don't bother caching any of these 
values.)