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

[Ian Bicking]

Phillip J. Eby wrote:
>>>> 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.
> 
> You should clarify that in the proposal itself, explicitly forbidding it 
> from being done by middleware unless the middleware is taking 
> responsibility for request processing, or the middleware clones the 
> environ.  Too many people, upon first encountering WSGI middleware, want 
> to use it to add things to the request API, when it isn't necessary.  
> Notice Hans Then's reaction to my -1 on middleware, for example.

OK, I'll clarify this.  Not that it's *horrible* that someone use this 
library function in middleware, but only if there's some reason specific 
to the middleware that they want to look at the POSTed form.  Middleware 
is a very vague concept, really, as anything that can forward the 
request onto another WSGI app is middleware, but many such things are 
themselves full applications.  (The specific example where this first 
really started bugging me was in paste.evalexception, which really is a 
bit of both application and middleware.)

But I will note that you should not parse the form unless you actually 
want it, not just so that it will show up in a parsed form for a later 
consumer.

> Writing correct middleware is already difficult, let's not encourage 
> people to write more incorrect middleware by increasing the temptation 
> to use middleware for trivial API enhancements that would be better done 
> as libraries.  (Yes, I know that wasn't your intent, but at least one 
> person besides me interpreted it as such.)
> 
> As far as the other open issues in the proposal, I don't really care 
> much.  My main concern is making sure that the proposal doesn't 
> encourage people to start creating middleware whose sole purpose is to 
> add unnecessary junk to environ while breaking other applications as a 
> side effect.  :)
> 
> (I do suggest, however, that a simpler way to assure WSGI compliance 
> when removing wsgi.input may be to set the incoming content-length to 
> zero.  An application or library that tries to read wsgi.input when the 
> content length is zero is itself non-compliant.)

That seems like an inaccurate representation of the request itself, and 
likely to cover up problems.  If you want to look at the POSTed form, 
and you aren't aware of this convention and the environment key, then 
there's an unresolvable error.  So it should just produce an exception; 
if you set CONTENT_LENGTH to 0 then the consumer will just happily 
assume there is no data, which leads to incorrect behavior.

I won't be able to update the spec right away, but when I get a chance I 
will do so.


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