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

Jeff King writes: > So I don't feel like we have a good patch for the general case yet, and > I'm probably not going to get around to implementing it anytime soon. So > I'd suggest taking David's original patch (to punt when the response is > empty) in the meantime. Yup, we are

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

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Friday, November 18, 2016 12:09 PM > To: David Turner > Cc: Junio C Hamano; git@vger.kernel.org; spea...@spearce.org > Subject: Re: [PATCH] remote-curl: don't hang when a server dies before any &g

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

On Fri, Nov 18, 2016 at 05:04:59PM +, David Turner wrote: > > So I don't feel like we have a good patch for the general case yet, > > and I'm probably not going to get around to implementing it anytime > > soon. > > I'm confused -- it sounds like your patch actually does work (that is, >

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

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Friday, November 18, 2016 12:02 PM > To: Junio C Hamano > Cc: David Turner; git@vger.kernel.org; spea...@spearce.org > Subject: Re: [PATCH] remote-curl: don't hang when a server dies before any > ou

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

On Tue, Nov 15, 2016 at 09:42:57AM -0800, Junio C Hamano wrote: > >> Hmph. I think I tried David's original under GIT_TEST_LONG and saw > >> it got stuck; could be the same issue, I guess. > > > > It works OK here. I think it is just that the test is really slow (by > > design). > > Yeah, I

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

Jeff King writes: > On Mon, Nov 14, 2016 at 05:02:27PM -0800, Junio C Hamano wrote: > >> Jeff King writes: >> >> > Actually, I take it back. I think it works for a single round of ref >> > negotiation, but not for multiple. Enabling GIT_TEST_LONG=1 causes it to >>

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

> -Original Message- > From: Jeff King [mailto:p...@peff.net] ... > I'll make that change and then try to wrap this up with a commit message. > I plan to steal your tests, if that's OK. Please do!

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

On Mon, Nov 14, 2016 at 05:02:27PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > Actually, I take it back. I think it works for a single round of ref > > negotiation, but not for multiple. Enabling GIT_TEST_LONG=1 causes it to > > fail t5551. > > > > I think I've

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

On Mon, Nov 14, 2016 at 07:44:26PM -0500, Jeff King wrote: > > But it does seem to work. At least it doesn't seem to break anything in > > the test suite, and it fixes the new tests you added. I'd worry that > > there's some obscure case where the response isn't packetized in the > > same way. >

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

Jeff King writes: > Actually, I take it back. I think it works for a single round of ref > negotiation, but not for multiple. Enabling GIT_TEST_LONG=1 causes it to > fail t5551. > > I think I've probably made a mis-assumption on exactly when in the HTTP > protocol we will see a

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

On Mon, Nov 14, 2016 at 02:40:49PM -0500, Jeff King wrote: > On Mon, Nov 14, 2016 at 01:24:31PM -0500, Jeff King wrote: > > > 2. Have remote-curl understand enough of the protocol that it can > > abort rather than hang. > > > > I think that's effectively the approach of your patch,

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

On Mon, Nov 14, 2016 at 11:25:30PM +, David Turner wrote: > > But it does seem to work. At least it doesn't seem to break anything > > in the test suite, and it fixes the new tests you added. I'd worry > > that there's some obscure case where the response isn't packetized > > in the same way.

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

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Monday, November 14, 2016 2:41 PM > To: David Turner > Cc: git@vger.kernel.org; spea...@spearce.org > Subject: Re: [PATCH] remote-curl: don't hang when a server dies before any > output > > On

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

On Mon, Nov 14, 2016 at 01:19:49PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > So something like this. It turned out to be a lot uglier than I had > > hoped because we get fed the data from curl in odd-sized chunks, so we > > need a state machine. > > It is

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

Jeff King writes: > So something like this. It turned out to be a lot uglier than I had > hoped because we get fed the data from curl in odd-sized chunks, so we > need a state machine. It is unfortunate that we have to snoop the protocol like this to infer an error, but I do not

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

On Mon, Nov 14, 2016 at 01:24:31PM -0500, Jeff King wrote: > 2. Have remote-curl understand enough of the protocol that it can > abort rather than hang. > > I think that's effectively the approach of your patch, but for one > specific case. But could we, for example, make sure

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

On Wed, Nov 09, 2016 at 05:18:30PM -0500, David Turner wrote: > 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. I agree we

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

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.