git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[RFC] Timeouts on HTTP requests

From
NHNick Hengeveld <nickh@reactrix.com>
Date
Oct 18, 2005, 23:51 UTC
Message-ID
<20051018235104.GO5509@reactrix.com>

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.

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?

-- 
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
Next: Junio C Hamano
Message 1 of 4 in “[RFC] Timeouts on HTTP requests”
  1. Nick HengeveldOct 18, 2005
  2. Junio C HamanoOct 19, 2005
  3. Petr BaudisOct 19, 2005
  4. Nick HengeveldOct 19, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.