Re: [PATCH] remote-curl: send Accept-Language header to server

From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: "lilinchao@oschina.cn" <lilinchao@oschina.cn>,
	Li Linchao via GitGitGadget <gitgitgadget@gmail.com>,
	git <git@vger.kernel.org>
Subject: Re: [PATCH] remote-curl: send Accept-Language header to server
Date: Tue, 05 Jul 2022 11:06:00 -0700	[thread overview]
Message-ID: <xmqqr12zjuyf.fsf@gitster.g> (raw)
In-Reply-To: <220705.86o7y3am2m.gmgdl@evledraar.gmail.com> (=?utf-8?B?IsOG?= =?utf-8?B?dmFyIEFybmZqw7Zyw7A=?= Bjarmason"'s message of "Tue, 05 Jul 2022 12:15:44 +0200")

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> It would make sense to call this protocol verb "setenv", and just give
> it support for setting arbitrary remote environment, which we'd then
> have a whitelist configuration variable for, similar to how sshd(1) does
> it.

Sounds like a security hole in the making, with dubious risk-benefit
tradeoff.  I cannot honestly answer favourably to this question if
somebody asked me as the project read: Are you solving a real-world
problem, or creating one?

> Or maybe we can just add this as a "capability", which seems like a more
> natural fit,

I took your suggestion upthread to be hinting this.

> we could even stick it into "agent" I guess...

But not this.

> Anyway, while it definitely would be an improvement to pass this along,
> a much better way to go IMO (but also harder) is to extend the protocol
> so that we don't a emita human language at all, but emit defined error
> states for our various known errors.

I would not go there.

The end that sends errors in status code may be running a newer
version of the software and the particular status code it sent is so
new that the receiving end does not know how to translate it into
human language.

Doing the Accept-Language at the HTTP level, or its equivalent at
the protocol-capability level, has the opposite problem that the
remote end may not know the requested language at all, but at least
the side that sends unlocalized messages is aware of it doing so.

Also the error message sideband carries the same messages that are
meant to be read by humans in Git subcommands that are run by the
protocol software as well as human users.  We could introduce such a
"error status code" language as an artificial locale, translate
_("...") messages into such "status code language" on the end that
sends errors, and then re-translate them into human language locale,
but it is of a dubious value.  Such an approach would not work well
at the gettext layer anyway, as we need to deal with placeholders,
so it would be a lot more involved than just "lets have catalog of
printf formatting templates and translate them".