From: Junio C Hamano Date: Thu, 10 Jul 2025 22:45:20 GMT Subject: Re: [PATCH 0/1] Filter C and POSIX out of Accept-Language Message-ID: In-Reply-To: <20250710221641.857081-1-sandals@crustytoothpaste.net> "brian m. carlson" 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? 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. Thanks. > brian m. carlson (1): > http: don't send C or POSIX in Accept-Language > > http.c | 8 ++++++++ > t/t5541-http-push-smart.sh | 18 ++++++++++++++++++ > 2 files changed, 26 insertions(+)