Re: [PATCH] credential-cache: interpret an ECONNRESET as on EOF

From: Jeff King <peff@peff.net>
Date: Jul 27, 2017, 14:47 UTC
Message-ID: <20170727144725.a72cybli746ipiko@sigill.intra.peff.net>
In-Reply-To: <6574cd23-5d95-c23c-8179-755798472a9d@ramsayjones.plus.com>

On Thu, Jul 27, 2017 at 03:42:36PM +0100, Ramsay Jones wrote:

> yep, I did think about adding a FLAG_EXIT (or somesuch) and passing
> it down through the call stack to send_request() so that I could do
> the check only for the 'exit' command. I decided against it in the
> end, obviously! ;-)

I had the same thought. I don't think it's worth the trouble, either.

Show 9 quoted lines

> > So I don't think this really changes the robustness much. If we did want
> > to address those cases, we'd require actual end-of-record framing in the
> > protocol. But I don't think it's worth caring too much about (this is,
> > after all, a local and internal socket between two relatively simple
> > programs).
> 
> Adding the framing to the protocol was actually my first (very fleeting)
> idea. However, I didn't want to get into the 'supporting old/new client
> and server combos' problem.

One nice thing about this protocol is that it's just between the caching client and server, which ship together and which run for a default of 5 minutes. I think it would probably be OK to just assume you have a matched pair, and change the protocol as you like.

So I'd be fine if somebody wanted to tackle this, but I don't think it matters that much. After all, it's proxying requests that came over the credential helper protocol, which also isn't framed. And changing that one _would_ be a compatibility problem.

-Peff