Re: [RFC/WIP PATCH 04/11] upload-pack-2: Implement the version 2 of upload-pack

From: Jeff King <peff@peff.net>
Date: May 27, 2015, 21:46 UTC
Message-ID: <20150527214616.GA23259@peff.net>
In-Reply-To: <CAGZ79kb6rsxpiXKg+eaVc+5bgUgPSaq+ocd-UHa=_K+rLxreTQ@mail.gmail.com>

On Wed, May 27, 2015 at 01:45:55PM -0700, Stefan Beller wrote:

Show 14 quoted lines

> > Right, but I think (and please correct me if there's a case I'm
> > missing) that the behavior is the same whether it is spelled
> > "ping-pong" or "capability:ping-pong". That is, the rule for
> > "capability:" is "if you do not understand it, ignore it and do not
> > mention it in your capabilities; the server is required to assume
> > you were written before that capability was invented". But that is
> > _also_ the rule for ping-pong, I think.
> 
> The rules are the same, right. But the allowed characters are limited
> (in theory) as the regular expressions given for the capabilities
> don't allow for binary data for example, but only well formed ASCII
> text, space separated.  The "ping-pong" keyword could introduce a
> binary stream there including line feeds. (Today it sounds like a
> stupid idea though)

Do we need that restriction? IOW, as long as we parse from the start of the packet and give up as soon as we realize it is not a thing we understand, I do not think anybody is hurt by the contents of the item.

E.g., if an old client sees:

   00XXping-pong=<binary goo>

It knows:

  1. The item starts with ping-pong; we don't know what that is, so we
     never even bother looking at the binary goo.

  2. It's in a pkt-line. We read to the end of the packet line and throw
     the rest of the data away. Now we're synchronized to read the next
     item.

Of course, "ping-pong" may also introduce another phase to the protocol which is not encapsulated in pkt-lines (e.g., if the data is too big to fit right inside the capability pkt-line, or if it needs a lot of back and forth like ref negotiation). But then we only proceed to that phase if both sides have said "I understand ping-pong".

So I think we are capable of boot-strapping just about anything using capability negotiation (with the exception of fixing the capability negotiation itself; but even that, we can bootstrap a second more intensive capability negotiation using a capability in the initial list).

-Peff