Re: [PATCH v6 1/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 3, 2017, 01:02 UTC
Message-ID: <xmqqr2sclj2q.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20171129032214.GB32345@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 10 quoted lines

>   3. For large inputs (like incoming packfiles), we connect the
>      descriptor directly to index-pack or unpack-objects, and they try
>      to read to EOF.
>
>      For a well-formed pack, I _think_ this would work OK. We'd see the
>      end of the pack and quit (there's a check for garbage at the end of
>      the pack, but it triggers only for the non-pipe case).
>
>      For a truncated input, we'd hang forever rather than report an
>      error.

Hmm. index-pack and/or unpack-objects would be fed directly from the incoming pipe, they are not told how many bytes to expect (by design), so they try to read to EOF, which may come after the end of the pack-stream data, and they write the remaining junk to their standard output IIRC.

For a well-formed pack, the above is what should heppen.

I am having trouble trying to come up with a case where the input stream is mangled and we cannot detect where the end of the pack-stream is without reading more than we will be fed through the pipe, and yet we do not trigger an "we tried to read because the data we received so far is incomplete, and got an EOF" error.

Wouldn't "early EOF" trigger in the fill() helper that these two programs have (but not share X-<)?