[Web-SIG] WSGI Open Space @ PyCon.

[Ionel Maries Cristian]

On Mon, Mar 30, 2009 at 14:14, Graham Dumpleton
<graham.dumpleton at gmail.com> wrote:
> 2009/3/30 Ionel Maries Cristian <ionel.mc at gmail.com>:
>> On Mon, Mar 30, 2009 at 03:13, Graham Dumpleton
>> <graham.dumpleton at 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