Consider this paragraph of PEP3333, referring to headers obtained
via start_response, emphasis mine:

    Instead, it must store them for the server or gateway to
    transmit only after the first iteration of the application
    return value that yields a *non-empty bytestring*, or upon
    the application's first invocation of the write() callable.

This means that an WSGI app such as this should be valid, because the
yielded bytes pre-start_response are empty:

    def application(environ, start_response):
        yield b''
        start_response("200 OK", [("Content-Type", "text/plain")])
        yield b'Hello, World.\n'

However, in wsgiref's simple server, this fails:

    Traceback (most recent call last):
      File "/usr/local/lib/python3.4/wsgiref/handlers.py", line 180, in finish_response
        self.write(data)
      File "/usr/local/lib/python3.4/wsgiref/handlers.py", line 269, in write
        raise AssertionError("write() before start_response()")
    AssertionError: write() before start_response()

Please see this paragraph of the spec (my emphasis added):

(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.)

The paragraph you quoted says that start_response() has to buffer headers until a non-empty string is yielded.  It does *not* say that strings can be yielded prior to calling start_response().  Indeed, the paragraph I quote above states the opposite: you can't call start_response() before yielding your first body string (whether empty or not).

This is a known issue with the spec, but it's an issue with the *spec*, not the implementation.  WSGI 1.0 is known to be unusable as a truly async API, for this and other reasons.

Fair enough, I misled myself.

However, and I feel like I'm getting really picky here, but it still doesn't fulfill the paragraph I quoted:

    def application(environ, start_response):
        start_response('200 OK',
                   [('Content-type', 'text/plain')])
        yield b''

        try:
            # produce an exception tuple, so we can re-call s_r
            raise RuntimeError
        except RuntimeError:
            # Headers shouldn't have been sent, but they were
            # so this will throw:
            start_response('200 OK',
                           [('Content-type', 'text/plain')],
                           sys.exc_info())
        yield b'error data or whatever'

But if async support a foregone conclusion anyway, is it worth bothering complying with that odd requirement?

You're right, it shouldn't send the headers until a non-empty string
occurs.  I don't see any problem with treating it as a bug, and fixing it.
Your patch will also allow non-compliant behavior, though.  It seems to me
it would be better to fix the logic in write() to not call send_headers()
if len(data)==0.  That way, it will still error with "write() before
start_response()" in the non-compliant case, but fix the compliance error.
Feel free to reopen/retitle this issue for that.

I agree, the current patch is too permissive.

Both a server I wrote a while ago, and most other "complaint" servers deal with the problem the exact same way as that patch, and that extra permissiveness led to my misinterpretation when analyzing why I had made that original change.

In any case, I've attached an updated patch.