On Mon, Oct 1, 2012 at 5:23 PM, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > From: "Shawn O. Pearce" <spearce@xxxxxxxxxxx> > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html