From: Junio C Hamano Date: Thu, 20 Sep 2012 06:31:32 GMT Subject: Re: [PATCH] Revert "retry request without query when info/refs?query fails" Message-ID: <7vhaqtciij.fsf@alter.siamese.dyndns.org> In-Reply-To: <7vlig5cilt.fsf@alter.siamese.dyndns.org> Junio C Hamano writes: > "Shawn O. Pearce" writes: > >> This reverts commit 703e6e76a14825e5b0c960d525f34e607154b4f7. >> >> Retrying without the query parameter was added as a workaround >> for a single broken HTTP server at git.debian.org[1]. The server >> was misconfigured to route every request with a query parameter >> into gitweb.cgi. Admins fixed the server's configuration within >> 16 hours of the bug report to the Git mailing list, but we still >> patched Git with this fallback and have been paying for it since. > > As the consequence of the above, the only two things we know about > the servers in the wild are (1) a misconfiguration that requires > this retry was once made, so it is not very unlikely others did the > same misconfiguration, and (2) those unknown number of servers have > been happily serving the current clients because the workaround > patch have been hiding the misconfiguration ever since. > > But as long as the failure diagnosis from updated clients that > revert this workaround is sufficient to allow such misconfigured > servers, I think it is OK. We might see a large number of small s/servers,/servers diagnosed,/; > people having to run around and fix the configuration as a fallout, > though. > >> Most Git hosting services configure the smart HTTP protocol and the >> retry logic confuses users when there is a transient HTTP error as >> Git dropped the real error from the smart HTTP request. Removing the >> retry makes root causes easier to identify. > > Does that hold true also for dumb only small people installations? > They are the ones that need more help than the large installations > staffed sufficiently and run smart http gateway. In any case, will queue.