From: Jeff King Date: Fri, 07 Apr 2017 04:48:23 GMT Subject: Re: [PATCH v3] http.postbuffer: allow full range of ssize_t values Message-ID: <20170407044823.cfqkd2xs2vxhgp4d@sigill.intra.peff.net> In-Reply-To: On Thu, Apr 06, 2017 at 07:24:54PM +0200, Christian Couder wrote: > > That would at least tell you if the problem is the chunked encoding, or > > if it's related to the size. > > The above commands work for me using gitlab.com and the log shows: > > Send header, 0000000309 bytes (0x00000135) > Send header: POST > /chriscool/yet-another-test-project.git/git-receive-pack HTTP/1.1 > Send header: Authorization: Basic > Send header: User-Agent: git/2.12.2.625.g14da1346c9.dirty > Send header: Host: gitlab.com > Send header: Content-Type: application/x-git-receive-pack-request > Send header: Accept: application/x-git-receive-pack-result > Send header: Content-Length: 4 > > Send header, 0000000341 bytes (0x00000155) > Send header: POST > /chriscool/yet-another-test-project.git/git-receive-pack HTTP/1.1 > Send header: Authorization: Basic > Send header: User-Agent: git/2.12.2.625.g14da1346c9.dirty > Send header: Host: gitlab.com > Send header: Accept-Encoding: gzip > Send header: Content-Type: application/x-git-receive-pack-request > Send header: Accept: application/x-git-receive-pack-result > Send header: Transfer-Encoding: chunked > > Maybe the reverse proxy doesn't like it when the push is really big. Interesting. So it is OK with the chunked encoding. It seems odd that it would complain about a bigger chunked encoding, but then work correctly with a single big buffer. But I guess it would all depend on what kind of buffering logic the reverse proxy uses. -Peff