Re: [PATCH 0/1] Filter C and POSIX out of Accept-Language

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jul 10, 2025, 23:08 UTC
Message-ID: <aHBH0nRLPxBg2HAj@fruit.crustytoothpaste.net>
In-Reply-To: <xmqqfrf34qdb.fsf@gitster.g>

[Dropping Yi EungJun from CC because their email bounced.]

On 2025-07-10 at 22:45:20, Junio C Hamano wrote:

Show 22 quoted lines

> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > At work, I've seen some cases where people provide "C" in the
> > Accept-Language header of their Git requests, such as when they provide
> > us with debugging traces, but "C" and "POSIX", while valid locales, are
> > not valid languages and do not belong in the Accept-Language header.
> >
> > It turns out this is actually very easy to reproduce and fix, so there's
> > a patch to filter these out.  I have not actually myself seen "POSIX" in
> > the header, but it's equivalent to "C" and I've seen it in non-Git
> > requests in various places online, so we reject that as well.
> >
> > This can be seen in GitLab's issues as well at
> > https://gitlab.com/gitlab-org/gitlab/-/issues/412077.
> 
> Sorry, I am confused.  Is that Authentication failure in the cited
> issue "caused by" the client sending "Accept-Language: C"?
> 
> "reproduce and fix" makes it sound like a correct exchange between
> such a client and a server is somehow broken (i.e. unable to clone,
> unable to authenticate, etc.) if the client sends C (or POSIX) as if
> it were a langauge, but is there a breakage there?

No, sorry. I just meant that the trace in that issue demonstrates the incorrect Accept-Language header; it's unrelated to the authentication problem that the issue is about (which I think is a GitLab issue).

Show 5 quoted lines

> I understand and agree with the change in patch 1/1 that it is the
> right thing to do (to more strictly adhere to the standard in what
> we send out) for hygiene.  I just want to understand if this caused
> real problems, or if it is primarily a preemptive clean-up to avoid
> non-standard behaviour causing problems in the future.

I'm not aware of it causing any practical problems for people, although I could imagine some cases where it could, in theory, break things. I merely noticed this in trace output and thought we should tidy it up. If users are using the header and expecting a localized response, this will make it more likely that they get the one they were expecting.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA