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

[Phillip J. Eby]

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.)


>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.