Fix multiple http authorization

[tomix1024]

TLDR Problem:
If the Authorization HTTP header is already configured via the (local) Git config for the domain where the LFS files are pulled from, Git LFS will send two Authorization HTTP headers, which constitutes and invalid HTTP request and is answered with a 400 Bad Request response by most HTTP servers.

TLDR Solution:
Make sure that there is always at most one Authorization header, when in doubt, Git LFS should override the local Git config.

I have a problem checking out Git LFS files in Gitea Actions using the actions/checkout@v4 action on my own server.
The Action configures the Authorization HTTP header for the base URL from where the repository is cloned.
The LFS files are served from the very same base URL.
When I run git lfs pull, git-lfs sets the Authorization header on its own, but then copies the extra HTTP headers from the Git config.

The Gitea server itself accepts these malformed HTTP requests.
However I am running the Gitea server behind an NGINX reverse proxy, which rejects these requests and does not forward them.

On Github the same error can be forced by cloning a private repository, and having the Authorization header configured for https://lfs.github.com, but why would anyone do this?

[bk2204]

Hey,

The behaviour we have here is the same behaviour that Git has, in that it will always add the additional header. This is why it's not suitable to use http.extraheader for authorization and it shouldn't be done. I don't believe we'll want to change the behaviour to diverge from Git here.

I'll expand on this to mention that we don't, in general, know which value is correct. It could be either one, which is why we can't simply choose one or the other.