Re: [PATCH v3] http.postbuffer: allow full range of ssize_t values

[Jeff King <peff@peff.net>]

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 <redacted>
> 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 <redacted>
> 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