On Wed, May 30, 2012 at 09:36:07AM +0500, Shahid wrote: > We have tried some use cases and found out that it is due to the fact that > we are holding the requests to send the response when available. The default > holding time is 60 seconds after that we send a TIMEOUT response. > > These kind of sockets never get closed by libevent on WAN. We have verified > that with special cases. > > Now we have investigated the code and found a way to forcefully close the > such HTTP connections within libevent. If we send an HTTP header in our > response "Connection: close" libevent will surely close the connection after > sending the response. > > We have verified that as well. > > My question here is whether this is a standard approach or we might get into > some other issues with it?
If your client is sending HTTP/1.1 requests without the header "Connection: close", keep-alive is assumed. This is the same for HTTP/1.0 with the "Connection: keep-alive" header. This is expected behaviour. Your solution is correct on the server side, another option is for the clients to tell the server to close the connection after 'n' transactions. *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
