On Sat, Mar 28, 2020 at 10:57:42AM -0400, Jeff King wrote: > But since it works for v1 (which also dies!), and since you were able to > reproduce the problem locally, I suspect it may be an issue in > upload-pack itself. Actually, I think the problem is on the client side. If I run your test without the http-backend change, then nothing is left running on the server side, but on the client we have two processes: git-clone and the git-remote-https helper. And they're deadlocked trying to read from each other. I think the issue is that git-remote-https in v2 mode calls into stateless_connect(), and just pumps http request/response pairs from git-clone to the server. But if a request generates an empty response, then clone has no idea that anything was received at all. It continues waiting, but remote-https has looped to expect another request from it. Your patch fixes _this case_ because it causes the server to send a non-empty response. But the client can't rely on that. Besides that not being a documented server behavior, in the worst case the connection could be severed mid-stream. So I think remote-https needs to complain about an empty response. This isn't a problem in v1 because it would actually try to look at that empty response; in v2 it's just proxying bytes around. -Peff
