{"thread":{"id":"2140","subject":"[RFC] Timeouts on HTTP requests","startedAt":"2005-10-18T23:51:04Z","lastAt":"2005-10-19T15:34:05Z","messageCount":4,"participants":["Nick Hengeveld","Junio C Hamano","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"10233","messageId":"20051018235104.GO5509@reactrix.com","threadId":"2140","inReplyTo":null,"subject":"[RFC] Timeouts on HTTP requests","fromName":"Nick Hengeveld","fromEmail":"nickh@reactrix.com","sentAt":"2005-10-18T23:51:04Z","receivedAt":"2005-10-18T23:51:04Z","isPatch":false,"sender":{"key":"nickh@reactrix.com","avatar":null},"body":"Our QA department today checked what would happen if the network connection\nwent away completely in the middle of an HTTP transfer. It looks as though\nthe answer is that git-http-fetch sits there forever waiting for CURL to\nreturn something.\n\nI'm thinking of taking advantage of CURL's capability of aborting a request\nif the transfer rate drops below a threshold for a specified length of time\nusing a new pair of environment variables and/or config file settings:\n\nGIT_HTTP_LOW_SPEED_LIMIT/http.lowspeedlimit\nGIT_HTTP_LOW_SPEED_TIME/http.lowspeedtime\n\nDoes this make sense, and if so should there be defaults if nothing is\nspecified?\n\n-- \nFor a successful technology, reality must take precedence over public\nrelations, for nature cannot be fooled.\n"},{"id":"10257","messageId":"7voe5mgi3d.fsf@assigned-by-dhcp.cox.net","threadId":"2140","inReplyTo":"20051018235104.GO5509@reactrix.com","subject":"Re: [RFC] Timeouts on HTTP requests","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-19T06:02:14Z","receivedAt":"2005-10-19T06:02:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nick Hengeveld writes:\n\n> Our QA department today checked what would happen if the network connection\n> went away completely in the middle of an HTTP transfer. It looks as though\n> the answer is that git-http-fetch sits there forever waiting for CURL to\n> return something.\n\nOuch.\n\n> I'm thinking of taking advantage of CURL's capability of aborting a request\n> if the transfer rate drops below a threshold for a specified length of time\n> using a new pair of environment variables and/or config file settings:\n>\n> GIT_HTTP_LOW_SPEED_LIMIT/http.lowspeedlimit\n> GIT_HTTP_LOW_SPEED_TIME/http.lowspeedtime\n>\n> Does this make sense, and if so should there be defaults if nothing is\n> specified?\n\nI suspect these would be quite different between DSL and\nlocalnet, so I doubt if there is a reasonable default value to\nquick give-up.\n\nOn the other hand, having _no_ activity for say 30 seconds would\nindicate a dead link on either modem or localnet.\n\nBTW, I've been thinking about giving defaults by shipping\ntemplates/config (i.e. no compile-time defaults). One trick I\nfound cute is to have \"clone.keeppack = 1\" in the templates to\nbe applied for any newly built repository, especially now\nkernel.org has git-daemon enabled.\n"},{"id":"10276","messageId":"20051019110909.GO30889@pasky.or.cz","threadId":"2140","inReplyTo":"7voe5mgi3d.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Timeouts on HTTP requests","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-10-19T11:09:10Z","receivedAt":"2005-10-19T11:09:10Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Oct 19, 2005 at 08:02:14AM CEST, I got a letter\nwhere Junio C Hamano told me that...\n> Nick Hengeveld writes:\n> \n> > Our QA department today checked what would happen if the network connection\n> > went away completely in the middle of an HTTP transfer. It looks as though\n> > the answer is that git-http-fetch sits there forever waiting for CURL to\n> > return something.\n> \n> Ouch.\n> \n> > I'm thinking of taking advantage of CURL's capability of aborting a request\n> > if the transfer rate drops below a threshold for a specified length of time\n> > using a new pair of environment variables and/or config file settings:\n> >\n> > GIT_HTTP_LOW_SPEED_LIMIT/http.lowspeedlimit\n> > GIT_HTTP_LOW_SPEED_TIME/http.lowspeedtime\n> >\n> > Does this make sense, and if so should there be defaults if nothing is\n> > specified?\n> \n> I suspect these would be quite different between DSL and\n> localnet, so I doubt if there is a reasonable default value to\n> quick give-up.\n> \n> On the other hand, having _no_ activity for say 30 seconds would\n> indicate a dead link on either modem or localnet.\n\nI agree that we should definitely use timeout instead of some low speed\nlimit - can't curl do that?\n\nBut 30 seconds is too little (on bad links, I've seen TCP connections\nstalled for much longer), I would use at least 120 seconds. Or perhaps\n30 seconds, but retry three times or so.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"10284","messageId":"20051019153405.GP5509@reactrix.com","threadId":"2140","inReplyTo":"20051019110909.GO30889@pasky.or.cz","subject":"Re: [RFC] Timeouts on HTTP requests","fromName":"Nick Hengeveld","fromEmail":"nickh@reactrix.com","sentAt":"2005-10-19T15:34:05Z","receivedAt":"2005-10-19T15:34:05Z","isPatch":false,"sender":{"key":"nickh@reactrix.com","avatar":null},"body":"On Wed, Oct 19, 2005 at 01:09:10PM +0200, Petr Baudis wrote:\n\n> > On the other hand, having _no_ activity for say 30 seconds would\n> > indicate a dead link on either modem or localnet.\n> \n> I agree that we should definitely use timeout instead of some low speed\n> limit - can't curl do that?\n\nCurl lets you set timeouts for the connect and the overall request, but\nneither of these are related to activity. In our case, some of the files\nwe transfer can be quite large and need to transfer over a 56K modem line.\nAs long as data is moving, we're happy; but we need the transfer to abort\nif the connection drops and data stops moving completely.\n\n> But 30 seconds is too little (on bad links, I've seen TCP connections\n> stalled for much longer), I would use at least 120 seconds. Or perhaps\n> 30 seconds, but retry three times or so.\n\nI've been testing with low speed limit of 1 and low speed time of 300 - if\ndata transfer stays below 1 byte/sec for 5 minutes, curl aborts the transfer.\n\nI like Junio's suggestion regarding defaults though, don't compile them in\nbut let default config templates take care of it.\n\n-- \nFor a successful technology, reality must take precedence over public\nrelations, for nature cannot be fooled.\n"}]}