Re: [RFC] Timeouts on HTTP requests

Dear diary, on Wed, Oct 19, 2005 at 08:02:14AM CEST, I got a letter
where Junio C Hamano [off-list ref] told me that...

Nick Hengeveld [off-list ref] writes:

quoted

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.

quoted

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.