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

[Ian Bicking]

(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 
> either:
> 
>   - 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 
deployments.

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