This patch was placed into 1.0.13, which I just released to PyPI (and to our
internal "lemonade" index).  Thanks again.

Thank you for the patch!

It appears that every piece of middleware I've ever written is broken in the
same way.

I'll apply this and make a new release after I write tests for your
wrap_generator function and the bit that calls it.  If you have tests, don't be
shy about committing them. ;-)

As repoze.who fails to handle the WSGI spec, and I'm supplying a working patch,
I'm bumping up the priority...

This is a bug in repoze.who because of this paragraph in PEP 333:

(Note: the application must invoke the start_response() callable before the
iterable yields its first body string, so that the server can send the headers
before any body content. However, this invocation may be performed by the
iterable's first iteration, so servers must not assume that start_response() has
been called before they begin iterating over the iterable.)

I've got a wrapper working, I'll implement it into repoze.who and submit a patch

The only way I can think to fix this is to create a new generator that wraps the
previous one.  It calls the wrapped generator once, caches that, and then yields
that and any further responses.  This allows the original generator to behave
the way it did before, and repoze.who can take a look at the status code.

If a WSGI application returns a generator expression, then
default_challenge_decider in classifiers.py tries to call status.startswith,
which blows up because status has not yet been decided (since the generator
hasn't been called yet)