[Web-SIG] Proposal: Handling POST forms in WSGI
Phillip J. Eby
pje at telecommunity.com
Tue Oct 24 19:52:54 CEST 2006
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
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
(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.)
More information about the Web-SIG