Re: [RFC] Timeouts on HTTP requests

From: Petr Baudis <pasky@suse.cz>
Date: Oct 19, 2005, 11:09 UTC
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 <junkio@cox.net> told me that...

Show 25 quoted lines

> Nick Hengeveld <nickh@reactrix.com> 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.