From: Jeff King <peff@peff.net>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: git@vger.kernel.org
Subject: Re: Issue with git clone via http/https and alternates
Date: Thu, 9 Dec 2021 23:08:17 -0500 [thread overview]
Message-ID: <YbLSsbBOtcFb0hIy@coredump.intra.peff.net> (raw)
In-Reply-To: <YbJgEnvuKm+GGXkd@linux-mips.org>
On Thu, Dec 09, 2021 at 08:59:14PM +0100, Ralf Baechle wrote:
> I'm hosting a number of largish repositories which being very similar
> are using git's alternates feature to save disk and memory. Cloning via
> git:// or ssh for users with accounts on the server works as expected but
> cloning via http or https results fails as follows:
>
> $ git clone http://git.linux-mips.org/pub/scm/linux-mti.git
> Cloning into 'linux-mti'...
> warning: alternate disabled by http.followRedirects: http://git.linux-mips.org/pub/scm/ralf/linux.git/
> error: Unable to find e4add961d4aaeb19f607f6d7bea8d59e1bd39ff0 under http://git.linux-mips.org/pub/scm/linux-mti.git
> Fetching objects: 11, done.
> Cannot obtain needed object e4add961d4aaeb19f607f6d7bea8d59e1bd39ff0
> while processing commit 9e2bf7cf7d9003c0f06736be5218ed79234f254c.
> error: fetch failed.
>
> Adding -c http.followRedirects=true will make the clone succeed. Question,
> shouldn't the default of http.followRedirects=initial already suffice?
There are security implications to allowing more redirects. See
cb4d2d35c4 (http: treat http-alternates like redirects, 2016-12-06).
That commit message does mention that we could be more lenient for
same-server redirects here, but AFAIK this is the first time anybody
cared enough to even bring it up the list.
That said...
> Anyway, what I'm looking for is something I can do serverside so users
> cloning the repository are not bothered with this http.followRedirects
> business. Is there anything I can do?
Turn on smart-http support for your server. The dumb-http protocol is
rather inefficient, and is what requires the client to even know about
your server-side alternates in the first place. And personally, I have a
lot less trust in it in general, compared to smart-http. There have been
tons of fixes and improvements in the smart-http code in the past 10
years, and I don't think anybody is really paying much attention to
dumb-http.
-Peff
prev parent reply other threads:[~2021-12-10 4:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-09 19:59 Issue with git clone via http/https and alternates Ralf Baechle
2021-12-10 4:08 ` Jeff King [this message]
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=YbLSsbBOtcFb0hIy@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=ralf@linux-mips.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox