Jim Fulton wrote: > I'm a bit unclear about the timing of the start_response call. > I think this is because the PEP is unclear, but perhaps I missed > something. > > It doesn't appear that the PEP says when the start_response callable > must be called. It gives several examples. In most, the callback is > called when the application is called, but in one example, the > callback is called in the __iter__ of the result of calling the > application. > > Here's what I think the PEP should say (something like): > > "The start_response callback must be: > > - called when the application is called, > > - called when the result iterator is computed, or > > - it must be called asynchronously, typically from an application > thread. > > Normally an application will call the start_response callable when the > application is called or when the result iterator is constructed, as > shown in the first 2 examples. An application, or more commonly, a > middleware component that provides it's own thread management might > delay starting the response. A server should not begin iterating > over the result until the start_response callable has been called."
My impression is that it is the application's responsibility to call start_response before the first item is returned from the iterator, and it is an error if it does not. However, in paste.lint (http://svn.pythonpaste.org/Paste/trunk/paste/lint.py) I check that start_response is called before the application returns the iterator. So I guess, at least where I've been inserting paste.lint, that I haven't encountered other examples in practice. But then most of the places I've used it, I wrote the application, and so I've never felt compelled to use a different order. If that's not correct, I'd like to update paste.lint. > Why do I want this? It appears that this would be needed to enable > middleware components that manage application threads. I can imagine > though that there aren't any existing servers that handle what I've > suggested correctly. > > I do think it would be straightforward for servers to handle this > correctly, especially for asynchronous servers like Twisted > and ayncore-based servers. Perhaps this could be an optional feature > of the servers. Servers supporting this feature would be prepared to > delay response output until start_response is called. Servers unable > to do this would generate errors if start_response hasn't been called > by the time the result iterator has been constructed. I suppose this wouldn't be particularly bad for threaded or multiprocess servers either -- they use a thread/process until the request is completed regardless of what happens. I can see how it could be used to greater effect in an asynchronous server. However, I'd rather it not be optional, as most WSGI apps won't do this, and so servers won't get good testing on this or may just not implement it, and then some apps and some servers won't be compatible. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ 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