Description
- Gitea version (or commit ref):
master - Git version: doesn't matter
- Operating system: doesn't matter
- Database (use
[x]): doesn't matter - Can you reproduce the bug at https://try.gitea.io: [x] Not relevant
Description
When Gitea gives LFS client links for objects verification/download, it tells client to use "Accept: application/vnd.git-lfs" HTTP header. However, LFS specification clearly states that client sends Accept: application/vnd.git-lfs+json. So, you're effectively forcing client into violation of LFS spec. While this happens to work with git-lfs that silently uses your Accept header instead of one from spec, things go much worse with different LFS client. git-lfs-java instead appends your Accept header so ends up with two Accept headers. But Gitea /verify handler only checks the first one, so rejects git-lfs-java requests.
I added a workaround to git-lfs-java so it can work with Gitea, though still believe you should fix stuff on Gitea side.
Here's an unfinished attempt to fix Gitea code by complete elimination of nonstandard "Accept: application/vnd.git-lfs" (such thing exists only in Gitea, it is NOT part of Git-LFS specification!), though it doesn't fully pass tests. Given that my Go skills are almost none, I hope you will fix this.