Re: [PATCH v2] remote-curl: don't hang when a server dies before any output

David Turner [off-list ref] writes:

In the event that a HTTP server closes the connection after giving a
200 but before giving any packets, we don't want to hang forever
waiting for a response that will never come.  Instead, we should die
immediately.

One case where this happens is when attempting to fetch a dangling
object by SHA.

Prior to this patch, fetch-pack would wait for more data from the
server, and remote-curl would wait for fetch-pack, causing a deadlock.

Despite this patch, there is other possible malformed input that could
cause the same deadlock (e.g. a half-finished pktline, or a pktline but
no trailing flush).  There are a few possible solutions to this:

1. Allowing remote-curl to tell fetch-pack about the EOF (so that
fetch-pack could know that no more data is coming until it says
something else).  This is tricky because an out-of-band signal would
be required, or the http response would have to be re-framed inside
another layer of pkt-line or something.

2. Make remote-curl understand some of the protocol.  It turns out
that in addition to understanding pkt-line, it would need to watch for
ack/nak.  This is somewhat fragile, as information about the protocol
would end up in two places.  Also, pkt-lines which are already at the
length limit would need special handling.

Both of these solutions would require a fair amount of work, whereas
this hack is easy and solves at least some of the problem.

Still to do: it would be good to give a better error message
than "fatal: The remote end hung up unexpectedly".

It seems to me that there is some gap/leap in the description
between the second and third paragraph above (i.e. the client asks
for an object, the server tries to see if the object is reachable
from the refs, and then what?  who waits for more data without
asking?), but other than that, including the future direction, the
proposed log message is very nicely described.

Thanks, will queue.