At 02:04 PM 10/21/2006, Ian Bicking wrote: >I've added another spec to wsgi.org: >http://wsgi.org/wsgi/Specifications/handling_post_forms > >This one is a little more intrusive than wsgi.url_vars, but it addresses >an outstanding source of problems: contention over wsgi.input.
-1 on this being middleware. If middleware wants to read the input, it should copy it to a temporary file or StringIO, not remove it. The broader principle here is that WSGI extensions should *add* to the WSGI specification, not subtract from it. Code running under middleware that does as you have proposed will be unable to use its own form processing or support nested applications. It's therefore not composable or further extensible, and I therefore have a hard time viewing the proposed middleware as being WSGI compliant. This is an extremely good example of something that belongs in a *library* and should not be done in middleware. Only end-application code that knows no further dispatching will occur is in a position to do destructive reading from wsgi.input. Middleware should be non-destructive, and should NOT be used where a library will suffice, since they add setup complexity and runtime performance overhead. The simple, standard way to do something like this would be to have a library routine like 'get_form_vars(environ)'. The routine would check for the form vars key, and if not present, then it would process the input and cache the information in the environment. It could even have an option to clone the input, in case the routine is being used from middleware. In general, where adding functionality doesn't require that the request or response be modified (as opposed to information simply being added to the environ), it should be done using library routines like this. There is no middleware setup or call-through overhead, and the calculation of additional environ entries only takes place if the information is actually used. There is also no need to use string constants as environ keys except in the routines themselves. This approach should be considered a best practice for *any* additions to the environ. _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
