[Web-SIG] Proposal: Handling POST forms in WSGI

[Ian Bicking]

Phillip J. Eby wrote:
> At 12:25 PM 10/24/2006 +0000, Hans Then wrote:
>> Phillip,
>>
>>> -1 on this being middleware.  If middleware wants to read the input,
>>> it should copy it to a temporary file or StringIO, not remove it.
>>> The simple, standard way to do something like this would be to have a
>>> library routine like 'get_form_vars(environ)'.  The routine would
>>> check for the form vars key, and if not present, then it would
>>> process the input and cache the information in the environment.  It
>>> could even have an option to clone the input, in case the routine is
>>> being used from middleware.
>> I think Ian's point is to standardise on a form key and on the interface of
>> the form object. Your point is valid that middleware should not
>> destructively read the wsgi.input variable.
>>
>> Many web applications will at some point call other web applications. It
>> seems positively wasteful to have to clone and parse wsgi.input over and
>> over again. It makes sense to do it once, in middleware, and then stuff it
>> in a standard place in the wsgi environ.
> 
> Re-read what I wrote.  If you have a common library routine, the parsing 
> (and optional cloning) only happens *once*.  If middleware needs access to 
> the data, it can just call the library routine.
> 
> This should NOT be implemented as middleware that adds the key; it's 
> completely unnecessary.  Middleware is only required for features that 
> actually *modify* or *monitor* the request or response, as opposed to 
> merely *adding* new request-side data derived from existing environ 
> keys.  If you want to improve the WSGI request API, the proper place to do 
> so is by using library routines that cache their computations in the 
> environ dictionary.
> 
> In fact, there isn't even any technical need to "officially" standardize 
> the environ keys for these functions.  Just release libraries that have the 
> features, so everyone can just install them.  Then we won't all have five 
> different libraries, each with its own routine just to do the same 
> 'get_form_vars()' operation!
> 
> Successful routines with sufficiently broad appeal and minimal impact could 
> then be targeted for inclusion in later versions of wsgiref (and ultimately 
> the stdlib).  This seems to me the cleanest overall way to add API 
> "friendliness" to WSGI.
> 
> (We could even discuss such things in the form of proposed patches to the 
> wsgiref code and documentation, then put them into the current wsgiref 
> release.)

That would be a landing place for an implementation of this library code 
that does what the spec implies.  But it relies on the release cycle for 
wsgiref, which is unclear and probably very slow since it is in the stdlib.

I have nothing against this being in wsgiref, I just would like to use 
this convention sooner rather than later.

>> Would you +1 the proposal if it is added that middleware does not destroy
>> the wsgi.input variable but clones it?
> 
> I didn't -1 the proposal, I -1'd middleware.  And the -1 
> stands.  Middleware is absolutely not the place for adding derivative 
> environ keys like this.  It's 100% unnecessary, adds complexity, and 
> reduces performance in the process.

Please respond to my proposal, which as I've clarified does not imply 
any particular middleware.


-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org