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 on the same page;
> -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 a
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,
> tha
> -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
&g
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 thin
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
>> > fail t5551.
>> >
>> > I thin
> -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!
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 probably made a mis-ass
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.
>
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 flush packet (and
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, b
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.
> -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
>
&g
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 unfortunate that we have t
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 think we can do
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 th
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
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.
18 matches
Mail list logo