Hi, 2014-11-01 21:19 GMT+09:00 Christian Grothoff <[email protected]>:
> On 11/01/2014 07:04 AM, Taehwan Weon wrote: > > I am testing reliability of my caching proxy based on MHD, which opens 80 > > port. > > It means anyone can use it to reach any web server. > > Most of incoming requests seems either incomplete or odd. > > Most!? Or do you mean "some"? > > Sorry, 'some' is correct. > > (I found a client opened a HTTP session and sent only a part of headers, > > but no body data.) > > > > 1. To avoid spurious EAGAIN, I add a counter into MHD_Connection, which > > counts continuous errors. If a threshold reaches, ECONNRESET set. EAGAIN > > seems caused by buffer full on client side. I am not sure what is the > > client's purpose. > > That's odd, TCP flow control should take care of that and simply not > present the (busy) connection as writable to the server userspace. > Still, if you are right, this suggests an easy way to > test for that condition -- by implementing a client that doens't > read the response and by sending a 'large' reply that won't fit > into the buffers. Have you tried this to reproduce the issue? > > I tested with my simple socket program where I changed the SO_RCVBUF to a small vaue). But I could not find any spurious EAGAINs from my test. But my proxy is still reporting the spurious EAGAINs. > > 2, To avoid infinite wait to receive remaining part of a client's data, I > > need timeout mechanism. > > I am not sure where is the best location to handle timeout. MHD or my > > caching proxy would be the candidate. > > I would say that virtually every MHD production site should set 'some' > timeout for MHD. Note that you can set a custom timeout for a > particular connection, i.e. when you know that a specific connection > will take way longer than usual. > > Ok. Thanks. Will be tried. :-) ------- weon
