From: Petr Baudis Date: Wed, 19 Oct 2005 11:09:10 GMT Subject: Re: [RFC] Timeouts on HTTP requests Message-ID: <20051019110909.GO30889@pasky.or.cz> In-Reply-To: <7voe5mgi3d.fsf@assigned-by-dhcp.cox.net> Dear diary, on Wed, Oct 19, 2005 at 08:02:14AM CEST, I got a letter where Junio C Hamano told me that... > Nick Hengeveld writes: > > > Our QA department today checked what would happen if the network connection > > went away completely in the middle of an HTTP transfer. It looks as though > > the answer is that git-http-fetch sits there forever waiting for CURL to > > return something. > > Ouch. > > > I'm thinking of taking advantage of CURL's capability of aborting a request > > if the transfer rate drops below a threshold for a specified length of time > > using a new pair of environment variables and/or config file settings: > > > > GIT_HTTP_LOW_SPEED_LIMIT/http.lowspeedlimit > > GIT_HTTP_LOW_SPEED_TIME/http.lowspeedtime > > > > Does this make sense, and if so should there be defaults if nothing is > > specified? > > I suspect these would be quite different between DSL and > localnet, so I doubt if there is a reasonable default value to > quick give-up. > > On the other hand, having _no_ activity for say 30 seconds would > indicate a dead link on either modem or localnet. I agree that we should definitely use timeout instead of some low speed limit - can't curl do that? But 30 seconds is too little (on bad links, I've seen TCP connections stalled for much longer), I would use at least 120 seconds. Or perhaps 30 seconds, but retry three times or so. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't.