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

[Shawn Pearce <spearce@spearce.org>]

On Fri, Jul 8, 2016 at 5:31 PM, Stefan Beller <sbeller@google.com> wrote:
> +
> +       /* 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.