On Wed, Feb 01, 2023 at 01:53:34PM +0100, Florian Bezdeka wrote:
> > The ideal, of course, would be an option to send the half-duplex
> > shutdown to the server and then wait for the server to hang up. But I
> > don't think it has such an option (you can just simulate it with a
> > really large "-t"). Netcat does, FWIW ("-q -1").
>
> -t doesn't help here. With massive help from the socat maintainer
> (thanks Gerhard!, now in CC) I was able to get the following log out of
> socat:
>
> 2023/02/01 11:06:29.960194 socat[18916] D read(0, 0x56111c858000, 8192)
> 2023/02/01 11:06:29.960208 socat[18916] D read -> 0
>
> stdin had EOF. Socat half closes the socket:
>
> 2023/02/01 11:06:29.960231 socat[18916] I shutdown(6, 1)
>
> And then, within less than 0.2s, the peer (proxy?) closes the other
> channel:
>
> 2023/02/01 11:06:30.118216 socat[18916] D read(6, 0x56111c858000, 8192)
> 2023/02/01 11:06:30.118238 socat[18916] D read -> 0
>
> It's quite clear now that the remote peer (proxy or server) closes the
> complete connection after receiving the partial shutdown. That's
> nothing that is under my control.
>
> With privoxy and the infrastructure at work (zscaler based) there are
> at least two proxy implementations showing this behavior.
OK, so the problem is that socat is not terminating at git-daemon, but
rather at some other random infrastructure that also does not handle
half-duplex shutdowns in a reasonable way. <sigh>
So if we took socat out of the loop entirely, and if raw git-over-tcp
did the half-duplex shutdown for the v2 protocol (which it really ought
to be doing), then those proxies would presumably similarly break.
I dunno. I am sympathetic that this thing used to work, and now doesn't.
But really the issue is in the v2 protocol, which has no way to signal
"I'm done" short of closing the socket. Combining that with raw
git-over-tcp and over-zealous proxies is going to be a problem.
> Switching to ncat --no-shutdown qualifies as workaround for now, but so
> far I didn't manage to get socat back into the game. Downgrading git is
> the other possibility.
Did you try setting protocol.version to 0? I expect that would also
work.
IMHO the best option, if possible, is to use git-over-http. It's more
secure and generally more tested than git-over-tcp.
-Peff
