Push to Azure DevOps GIT LFS aborts regardless of the HTTP version setting to HTTP/1.1

Question

I'm trying to use the GIT LFS from Azure DevOps to push really big files, but the push always get aborted after 120 seconds. Currently only an ISO with ~2,4 GB, but later I planned to upload probably something around the maximum of 50 GB.

I created an empty repository in Azure DevOps and prepared it for GIT LFS. I also set the HTTP version to HTTP/1.1.

git lfs install
git config --global http.version HTTP/1.1
git clone <SOME_COOL_PROJECT> test
cd test
# move big file into test directory
git lfs track directory_with_big_files/*
git add .
git commit -m 'initial commit'
git push origin main

When I execute the git push origin main, it will abort the upload to GIT LFS after 120 seconds with an 503 Fatal error: Server error.

I'm pretty sure, that I pushed in the past big files to GIT LFS in Azure DevOps. I tried this on Windows and Linux, but the behavior seems the same. I also tried to change the lfs.dialtimeout and lfs.activitytimeout, but it always abort after 120 seconds.

Maybe someone has an idea?

---

Update

Meanwhile a college found a solution (sadly no explanation) on a another computer which a better internet connection. He managed to push the big file and we found out that our .git/config file is different.

For some reason after one successful upload of a single GIT LFS file, git adds the following setting into the .git/config file.

[lfs "<SOME_COOL_PROJECT>.git/info/lfs"]
    access = basic
+[lfs "<SOME_COOL_PROJECT>/info/lfs/objects/"]
+    access = basic

If I manually add the /info/lfs/objects/ on my local machine with the bad internet connection I can upload the big file.

But why? Maybe someone has a deeper knowledge of why or how the mechanism works which enters this settings to the .git/config

---

https://learn.microsoft.com/en-us/azure/devops/repos/git/manage-large-files?view=azure-devops#limitations

https://github.com/MicrosoftDocs/azure-devops-docs/issues/4179

Answer 1

A 503 HTTP status means that service is unavailable. Like other 5xx status codes, this indicates a problem on the server side that the client has no control over. If there were something you could do to influence the problem, you'd have received a 4xx status code, which is a client error, and then you'd take appropriate action to do something different.

Note that the comment suggesting setting http.postBuffer isn't useful. Git LFS doesn't use that option at all, and the Git FAQ is clear that it shouldn't be needed for Git unless the remote server or a proxy is seriously broken. I assume the Azure DevOps team is at least minimally competent and has used an HTTP server that handles chunked transfer encoding properly.

It could well be, however, that you have a proxy (including a non-default antivirus or firewall, or monitoring software) that is tampering with your connections and sending the 503 instead. In Git Bash, you can precede your push with GIT_TRACE=1 GIT_TRANSFER_TRACE=1 GIT_CURL_VERBOSE=1 to see more information about the operation, including the HTTP request and response. If you think it might be some sort of proxy, you should try another network, and if you're using such software on your machine, you should completely uninstall it and reboot and try again to see if that fixes it. (Oftentimes simply disabling it is not effective.)

You can also try under WSL to see if that fixes the problem. If so, it very likely is some sort of proxy software, but at least you'll have more information on what might be related.