I would be fine with adding support for this to Brubeck + Mongrel2 if necessary.
Brubeck also supports WSGI, btw, but no logic has been added to support multipart outputs as you're describing. I think it's a good idea. On Fri, Jan 4, 2013 at 2:15 PM, Matthew Hawn <[email protected]> wrote: > My two cents worth: > > I looked at Brubeck pretty closely a while ago and from what I can tell, > Brubeck uses its own API to communicate with web applications. That API > specifies the entire body is returned by the Application, in contrast to > WSGI which specifies an iterable. In this way, Brubeck can always return > a complete message, with a Content-Length. This makes Brubeck's task > simpler but you lose some of the flexibility of multipart responses. (By > the way, I actually really like how Brubeck is structured, its just not > right for my project) > > However, I think all mongrel2 handlers should deal with connection closing > for the following reasons: > > Specification adherence: For HTTP 1.0, if the request does not include a > Connection: Keep-Alive, the connection is closed after the response. For > HTTP 1.1, if the request includes Connection: close, the connection is > closed after the response. Most clients will still work without this, but > there are some that really do expect the connection to be closed. Mongrel2 > does not handle any of this for us (except for directory routes) > > Unknown Content Length: For some handlers, content-length may not be known > at the time headers are sent. If the client supports chunked transfer > encoding, that can be used. If not (HTTP 1.0 clients), the connection has > to be closed to signify the end of response. This is where I am running > into trouble with a mongrel2->wsgi handler. WSGI client applications > USUALLY send everything as a single chunk and I can calculate > Content-Length, but there may be a rare case where this is not true. Also, > WSGI spec specifies that the output NOT be buffered up and sent as a single > response. > > In addition, it seems to be good practice: If a client says, "Hey, after > this request, I'm done. Thanks!" (Connection: close), we should close the > connection for reuse. The mechanism is actually already in Mongrel2, it > just seemed to break a while ago. > > I have looked at a couple other Mongrel2 handlers, and some of the others > do do explicit closes (sending a blank message). In fact, even Brubeck does > this with Connection.close_bulk. > > Matt > > ------------------------------ > *From:* James Dennis <[email protected]> > *To:* [email protected] > *Sent:* Friday, January 4, 2013 11:19 AM > > *Subject:* Re: [mongrel2] Closing Connections with empty message > > Last I checked, the connections just naturally time out if you're done > with them. I spoke with Zed about it and we agreed the right way to handle > it is to do nothing from Brubeck's side. > > > On Thu, Jan 3, 2013 at 6:56 PM, Dalton Barreto <[email protected]>wrote: > > > > > 2012/12/31 James Dennis <[email protected]> > > Hello Matt. > > I too have written a Python handler for Mongrel2. > > Did you check out Brubeck by any chance? > > > Hello James, > > Do you know how does brubeck deals with this problem (sending mongrel2 > small messages and a final empty msg)? > > Thanks, > > Dalton Barreto > http://daltonmatos.com > > > > >
