On 2012-05-17 21:16, Justin Karneges wrote: > This week I noticed that Mongrel2's python library doesn't issue close > messages by default. Of course this is to ensure streaming works, but for > some > reason I figured if Content-Length was passed and enough content sent, then > either the python library would send a close message or Mongrel2 would > automatically close the connection but it turns out that neither of these > things actually happen. > > Curl and pretty much every browser seems to receive HTTP responses just fine > with this behavior. But some other clients are pickier, and need the explicit > close (like Pingdom for example). I'm not sure what the right server behavior > is, but I've started issuing explicit close messages from my handlers when my > intention is that the HTTP response is complete. > > I don't know if this is the issue you're seeing, but I'm mentioning it just > in > case.
More than just in case. What you are mentioning here is also a reason some of the users are advocating a tnetstring answer from the handler to M2 and not just a raw message. As you send a raw message at the moment, outside of the "empty message" hack to close a connection from the handler (or accessing the control port), you cannot do more. With a tnetstring for M2, we could tell M2 to close the connection at the end, rate limit, consider the message as "non valuable" in the case of streaming, so if the buffer is full, just drop the message, etc. Way more control, cleanly encapsulated. loïc > On Thursday, May 17, 2012 11:49:00 AM Alberto Salce wrote: >> Could this be related to why ApacheBenchmark and Mongrel2 don't get >> along. AB just hangs like if the connections are not being accepted. >> Siege works just fine. >> >> On 5/17/2012 12:14 PM, Rob LaRubbio wrote: >>> I'm trying to write a filter that I can use to track how long requests >>> are taking to run through my system. The filter is pretty simple, it >>> just intercepts the REQ_RECV and RESP_SENT states, tracks the time of >>> each and prints it. >>> >>> When I run my filter and access my server with a browser I see both >>> states execute and the filter correctly prints the time. However if I >>> access my server using curl on the command line I only see REQ_RECV. I >>> do see the response from my service in the terminal and the curl command >>> returns. I've also tried different combination of states with HANDLER& >>> CLOSED but I still see the same results. I'm a little stumped by this >>> so any suggestions on where to look next would be really helpful. >>> >>> -Rob -- Dr Loïc d'Anterroches Founder Céondo Ltd w: www.ceondo.com | e: [email protected] t: +44 (0)207 183 0016 | f: +44 (0)207 183 0124 Céondo Ltd Dalton House 60 Windsor Avenue London SW19 2RR / United Kingdom
