[Web-SIG] Proposal: Handling POST forms in WSGI
ianb at colorstudy.com
Tue Oct 31 20:12:05 CET 2006
(Copied back to the list)
Andrew Clover wrote:
> Ian Bicking <ianb at colorstudy.com> wrote:
> > When this happens, the form can be parsed by ``cgi.FieldStorage``.
> Agree with the objections others have posted.
> There are many alternative things one might want to do with the body
> that don't involve the cgi module (which is old, frequently inconvenient
> and offers poor performance in some areas). Please leave the decision on
> what to do with the contents of wsgi.input to the discretion of a
> higher-level framework/middleware component.
This does not require anyone to use the cgi module. This addresses what
you can do when you do use the cgi module (which realistically is what
everyone does -- I've literally never seen an exception, though I
imagine there are one or two somewhere). It needs to be clarified that
parsing should still be done lazily and deferred as long as possible,
but when it doesn't get deferred this offers a simple solution for later
consumers that also use cgi.FieldStorage.
> I have more sympathy for the idea of keeping a copy of the entire POST
> request so it can be read again (eg. by having a component that consumes
> wsgi.input replace it with a StringIO returning the same content).
> However I don't see *mandating* this as a good move, given that a POST
> can contain multimegabyte file uploads.
Keeping the POST request feels heavy considering it usually isn't
needed. The proposal requires very little overhead.
> How about asking that something that consumes wsgi.input replace it with
> - the original stream seek()ed to 0, if possible;
Possible; depends on the deployment and the middleware involved.
Requiring seek to work means that code will only work in particular
> - a new streamlike echoing the post request;
This would be nice, and would allow for smart intermediaries to be
compatible with dumb consumers, and potentially smart consumers could
skip reparsing without any overhead. I don't have any code to do this.
If code to do this emerged, it would be very reasonable to
InputProcessed in the spec with this better implementation.
Note of course if you parse with cgi, throw the original body away, then
recreate the body from the FieldStorage object, it is unlikely that you
can improve on the cgi module in any way. Only if you get first crack
at wsgi.input can you improve it.
> - or a None or dummy stream which will guarantee a quick exception
> if the stream is re-read later, rather than just mysteriously
> blocking forever?
This is part of my proposal.
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Web-SIG