From: Junio C Hamano Date: Wed, 19 Oct 2005 06:02:14 GMT Subject: Re: [RFC] Timeouts on HTTP requests Message-ID: <7voe5mgi3d.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <20051018235104.GO5509@reactrix.com> 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. BTW, I've been thinking about giving defaults by shipping templates/config (i.e. no compile-time defaults). One trick I found cute is to have "clone.keeppack = 1" in the templates to be applied for any newly built repository, especially now kernel.org has git-daemon enabled.