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

Re: [PATCH] Retry HTTP requests on SSL connect failures

From
DNDrew Northup <n1xim.email@gmail.com>
Date
Oct 2, 2012, 00:14 UTC
Message-ID
<CAM9Z-nkSio-fXPAw_qaZsPhT-DHjn+AOOfZMXQYFCmeQAs+cJA@mail.gmail.com>
In-Reply-To
<1349126586-755-1-git-send-email-spearce@spearce.org>
On Mon, Oct 1, 2012 at 5:23 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
Show 17 quoted lines
> From: "Shawn O. Pearce" <spearce@spearce.org>
>
> When libcurl fails to connect to an SSL server always retry the
> request once. Since the connection failed before the HTTP headers
> can be sent, no data has exchanged hands, so the remote side has
> not learned of the request and will not perform it twice.
>
> In the wild we have seen git-remote-https fail to connect to
> some load-balanced SSL servers sporadically, while modern popular
> browsers (e.g. Firefox and Chromium) have no trouble with the same
> server pool.
>
> Lets assume the site operators (Hi Google!) have a clue and are
> doing everything they already can to ensure secure, successful
> SSL connections from a wide range of HTTP clients. Implementing a
> single level of retry in the client can make it more robust against
> transient failure modes.

Ok, this begs for some background info... @Dayjob one of the many things I do is mange our load balancers (redundant pair in our case). If the attempted SSL connections in one "bin" (time-slot) exceeds the licensed size of that "bin" then the excess attempts are just "dropped on the floor." Normal web browsers detect this initial failure and try again. This may be implemented internally—I haven't checked.

Google, as I am sure you are well aware, doesn't rely upon a traditional L2/L3 network level load balancing architecture. Therefore, I would not attempt to argue that the results that apply to their systems would apply much of anywhere else. (They have done presentations publicly, which are archived on the 'net, about how they do things.)

-- 
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
Previous: Drew NorthupNext: Junio C Hamano
Message 33 of 36 in “Disable dumb HTTP fallback with GIT_CURL_FALLBACK=0”
  1. Disable dumb HTTP fallback with GIT_CURL_FALLBACK=0Shawn O. Pearce, Sep 20, 2012
  2. Shawn PearceSep 20, 2012
  3. Jeff KingSep 20, 2012
  4. Jeff KingSep 20, 2012
  5. Shawn PearceSep 20, 2012
  6. Revert "retry request without query when info/refs?query fails"Shawn O. Pearce, Sep 20, 2012
  7. Junio C HamanoSep 20, 2012
  8. Junio C HamanoSep 20, 2012
  9. Jeff KingSep 20, 2012
  10. 0/2 smart http toggle switch fails"Jeff King, Sep 20, 2012
  11. 1/2 remote-curl: rename is_http variableJeff King, Sep 20, 2012
  12. 2/2 remote-curl: let users turn off smart httpJeff King, Sep 20, 2012
  13. Junio C HamanoSep 20, 2012
  14. Jeff KingSep 20, 2012
  15. Junio C HamanoSep 20, 2012
  16. Jeff KingSep 20, 2012
  17. Junio C HamanoSep 20, 2012
  18. Jeff KingSep 20, 2012
  19. Junio C HamanoSep 21, 2012
  20. Jeff KingSep 21, 2012
  21. Jeff KingSep 20, 2012
  22. Shawn PearceSep 20, 2012
  23. Jeff KingSep 21, 2012
  24. Shawn PearceSep 21, 2012
  25. Retry HTTP requests on SSL connect failuresShawn O. Pearce, Oct 1, 2012
  26. Junio C HamanoOct 1, 2012
  27. Junio C HamanoOct 1, 2012
  28. Jeff KingOct 1, 2012
  29. Junio C HamanoOct 1, 2012
  30. Jeff KingOct 1, 2012
  31. Shawn PearceOct 2, 2012
  32. Drew NorthupOct 2, 2012
  33. Drew NorthupOct 2, 2012
  34. Re* [PATCH] Disable dumb HTTP fallback with GIT_CURL_FALLBACK=0Junio C Hamano, Sep 20, 2012
  35. 1/2 Disable dumb HTTP fallback with GIT_DUMB_HTTP_FALLBACK=falseJunio C Hamano, Sep 20, 2012
  36. 2/2 remote-curl: make dumb-http fallback configurable per URLJunio C Hamano, Sep 20, 2012

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.