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

[Phillip J. Eby]

At 11:56 AM 10/24/2006 -0500, Ian Bicking wrote:
>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.

Not really.  wsgiref is distributed standalone from the cheeseshop, so 
newer versions are just an easy_install away.


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

Of course; the wsgiref thing was just a suggestion for where canonical 
implementations of these things would live.


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

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