"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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(+)
