All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Shawn O. Pearce" <spearce@spearce.org>, git@vger.kernel.org
Subject: Re: [PATCH] Revert "retry request without query when info/refs?query fails"
Date: Thu, 20 Sep 2012 12:24:56 -0400	[thread overview]
Message-ID: <20120920162456.GA25418@sigill.intra.peff.net> (raw)
In-Reply-To: <7vlig5cilt.fsf@alter.siamese.dyndns.org>

On Wed, Sep 19, 2012 at 11:29:34PM -0700, Junio C Hamano wrote:

> "Shawn O. Pearce" <spearce@spearce.org> 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.

The misconfiguration was pretty wild in this case. I'd be much more
worried about stupidly non-compliant servers that will not serve
"foo/bar" when asked for "foo/bar?key=value".

> 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
> people having to run around and fix the configuration as a fallout,
> though.

I think Shawn's revert is the right thing to do. But it is not complete
without the manual workaround. I'm putting that patch together now and
should have it out in a few minutes.

> > 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.

For the most part, yes. They will get a useful error out of the smart
request if there is a transient error, the repo does not exist, etc.
The real fallout is the people who are hitting a broken or misconfigured
server and may get a confusing error code (in the one case we know
about, it was a 404, but it really could be anything, depending on the
exact nature of the misconfiguration).

-Peff

  parent reply	other threads:[~2012-09-20 16:25 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-20  2:55 [PATCH] Disable dumb HTTP fallback with GIT_CURL_FALLBACK=0 Shawn O. Pearce
2012-09-20  3:22 ` Shawn Pearce
2012-09-20  3:52   ` Jeff King
2012-09-20  3:48 ` Jeff King
2012-09-20  5:57   ` Shawn Pearce
2012-09-20  5:58     ` [PATCH] Revert "retry request without query when info/refs?query fails" Shawn O. Pearce
2012-09-20  6:29       ` Junio C Hamano
2012-09-20  6:31         ` Junio C Hamano
2012-09-20 16:24         ` Jeff King [this message]
2012-09-20 16:59           ` [PATCH 0/2] smart http toggle switch fails" Jeff King
2012-09-20 17:00             ` [PATCH 1/2] remote-curl: rename is_http variable Jeff King
2012-09-20 17:05             ` [PATCH 2/2] remote-curl: let users turn off smart http Jeff King
2012-09-20 17:53               ` Junio C Hamano
2012-09-20 18:12                 ` Jeff King
2012-09-20 18:36                   ` Junio C Hamano
2012-09-20 20:51                     ` Jeff King
2012-09-20 21:15                       ` Junio C Hamano
2012-09-20 21:30                         ` Jeff King
2012-09-21 17:34                           ` Junio C Hamano
2012-09-21 17:41                             ` Jeff King
2012-09-20 17:24     ` [PATCH] Disable dumb HTTP fallback with GIT_CURL_FALLBACK=0 Jeff King
2012-09-20 23:05       ` Shawn Pearce
2012-09-21  5:26         ` Jeff King
2012-09-21 14:19           ` Shawn Pearce
2012-10-01 21:23             ` [PATCH] Retry HTTP requests on SSL connect failures Shawn O. Pearce
2012-10-01 21:47               ` Junio C Hamano
2012-10-01 21:53               ` Junio C Hamano
2012-10-01 22:23                 ` Jeff King
2012-10-01 23:20                   ` Junio C Hamano
2012-10-01 22:18               ` Jeff King
2012-10-02  2:38                 ` Shawn Pearce
2012-10-02 13:57                   ` Drew Northup
2012-10-02  0:14               ` Drew Northup
2012-09-20  4:14 ` Re* [PATCH] Disable dumb HTTP fallback with GIT_CURL_FALLBACK=0 Junio C Hamano
2012-09-20  4:14   ` [PATCH 1/2] Disable dumb HTTP fallback with GIT_DUMB_HTTP_FALLBACK=false Junio C Hamano
2012-09-20  4:14   ` [PATCH 2/2] remote-curl: make dumb-http fallback configurable per URL Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120920162456.GA25418@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.