On Mon, Mar 30, 2009 at 14:14, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > 2009/3/30 Ionel Maries Cristian <ionel...@gmail.com>: >> On Mon, Mar 30, 2009 at 03:13, Graham Dumpleton >> <graham.dumple...@gmail.com> wrote: >> [...] >> >>> The problem with this is what happens if a WSGI middleware tries to do >>> something with it. If the separate change is made to allow string like >>> objects to be returned instead of only string objects, then its string >>> like behaviour could be to appear like an empty string. Thus a >>> middleware would see it as an empty string. Of course, the WSGI >>> middleware then may suppress it and not pass it back down the line. >>> >>> As with wsgi.file_wrapper, the problem is that only the WSGI adapter >>> really knows what the type of the iterable instance being returned is, >>> a WSGI middleware can't work it out, except maybe by creating a dummy >>> instance of one and comparing the types. Even then, that may not be >>> guaranteed. >>> >>> This therefore makes it hard for a WSGI middleware to even detect such >>> special control/meta elements and simply pass them through. That also >>> wouldn't work anyway, as a WSGI middleware could be trying to combine >>> together all the strings into one big string to stick a content length >>> on it. In that case it isn't going to even know that a special control >>> element is saying that it should stop trying to do that and instead >>> flush out what it has already accumulated so that underlying server >>> can do other stuff while waiting for file descriptor to be ready. >>> >>> A WSGI middleware doing this sort of thing is going to screw you up >>> even if empty string as might be getting used for this purpose now. In >>> short, I can't see how you can do it this way, as you have no >>> guarantee that a WSGI middleware will not hold on to it. Thus never >>> gets back to underlying WSGI adapter. >>> >> >> That's wrong - middleware should not eat up response chunks. >> >> To quote the wsgi spec: >> To put this requirement another way, a middleware component >> must yield at least one value each time its underlying application >> yields a value. If the middleware cannot yield any other value, >> it must yield an empty string. >> See: >> http://www.python.org/dev/peps/pep-0333/#middleware-handling-of-block-boundaries > > In practice I doubt that that is being applied consistently and you > thus can't rely on it. > > Even so, any WSGI middleware still needs a way of detecting these > control/meta elements and know it has to pass them through straight > away. They can't just pass back an empty string in place of them as > that defeats the purpose of them. > > Graham >
Meta/control elements could be saved somewhere on a special object in the environ and empty strings can just be a notification we need to check that object for the meta/control element. This way should penetrate all middleware that comply to the rules in the wsgi spec. There is not so much middleware that breaks this - I only know of error capturing middleware - but those are acceptable offenders. Either way, it's easy to fix. -- ionel _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com