[Web-SIG] When must applications call the WSGI start_response callable.

[Ian Bicking]

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  /  ianb at colorstudy.com  /  http://blog.ianbicking.org