lfshttp: only add extra headers if they don't exist already

[larsxschneider]

In actions/checkout#415 @Roda83 noted that Git LFS files are not downloaded within the GitHub Actions environment on GitHub Enterprise Server in certain cases.

The checkout@v2 action uses Git's extraheader config to make the authentication easily available to all Git calls in the Action environment. At some point the Action runs git lfs fetch to download the LFS files and this works great.

This call will download the "metadata" of the LFS files in batch with a href and an authentication header for each LFS file. Git LFS uses this info to make additional requests to download these files. Usually, these LFS files are downloaded from a different domain than the domain that the repository is cloned from (e.g. media.ghes-server.com vs ghes-server.com). That's why the extraheader is not applied to these requests.

However, if GitHub Enterprise Server is not run in "subdomain isolation" mode, then the clone domain is equal to the LFS files domain. Consequently, the extraheader is applied. That means the requests will have two authentication headers and because of that the request will fail.

This PR fixes this issue by checking if a certain header already exists before we add an extraheader.

---

I tried to add a test case for this but it turns out that the LFS batch response in our tests does not contain an authentication header. Therefore, we have no duplicate header and no problem.

/cc @dassencio @jonico

[bk2204]

Unfortunately, we can't do this, because there are a small number of HTTP headers which can be repeated and users should be able to specify multiple entries for those. That's why Go provides a slice for its HTTP header entries instead of a string. Authentication is not one of those, which is why we correctly reject it on the server side.

The proper solution to this is that GitHub Actions should not use http.extraheader at all. This has been reported as a bug, but it wasn't fixed due to Apple Git having some broken caching behavior for credential helpers. It would be better for GitHub Actions to specifically reject a broken Git and use the correct credential helper approach, which would avoid this problem.

[bk2204]

I'm going to close this, since this isn't a viable approach at the moment, and the solution has been well stated elsewhere (use a credential helper). Note that the GitHub Git daemon also now rejects multiple authentication headers as well as GitHub's LFS server, so everyone should be equally unhappy when using http.extraheader.