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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 5, 2022, 18:06 UTC
Message-ID: <xmqqr12zjuyf.fsf@gitster.g>
In-Reply-To: <220705.86o7y3am2m.gmgdl@evledraar.gmail.com>

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