Re: [PATCH 2/4] receive-pack: implement advertising and receiving push options

From: Shawn Pearce <spearce@spearce.org>
Date: Jul 10, 2016, 17:06 UTC
Message-ID: <CAJo=hJtUyF=-iZeA1qBi42KBCP0pE6KsK4_MDP4JZEOf-K0waQ@mail.gmail.com>
In-Reply-To: <20160709003113.26930-3-sbeller@google.com>

On Fri, Jul 8, 2016 at 5:31 PM, Stefan Beller <sbeller@google.com> wrote:

Show 13 quoted lines

> +
> +       /* NEEDSWORK: expose the limitations to be configurable. */
> +       int max_options = 32;
> +
> +       /*
> +        * NEEDSWORK: expose the limitations to be configurable;
> +        * Once the limit can be lifted, include a way for payloads
> +        * larger than one pkt, e.g allow a payload of up to
> +        * LARGE_PACKET_MAX - 1 only, and reserve the last byte
> +        * to indicate whether the next pkt continues with this
> +        * push option.
> +        */
> +       int max_size = 1024;

Instead of this, what about a new config variable receive.maxCommandBytes[1] that places a limit on the number of bytes of pkt-line data the client can supply in both the command list ("old new ref"), push signature framing, and option list?

Memory demands for the server are proportional to the data sent. A simple byte limit lets the user make the decision about how this gets used. Longer ref names or option values means fewer refs or options can be sent. Shorter ref names or option values means more values or options can be sent.

I studied a lot of repositories[2] and most use ref names under 200 bytes in length. A 3 MiB default for receive.maxCommandBytes gives users something like 11,115 references in a single git push invocation if they used all 200 bytes in every name. Most users don't have ref names this long. Unlike a cap on each ref, it allows users to use the full 65449 bytes in a reference name available in pkt-line, but you can only send 48 such references. Likewise for options. :)

[1] I may propose this to JGit. [2] More than 3M, but maybe Peff has access to more.