upload-pack: accept only a single packfile-uri line
commit179776f9e6c4bd2f423c78fcf8b1e4cb4afc4c45
authorJeff King <peff@peff.net>
Wed, 28 Feb 2024 22:38:46 +0000 (28 17:38 -0500)
committerJunio C Hamano <gitster@pobox.com>
Wed, 28 Feb 2024 22:42:01 +0000 (28 14:42 -0800)
tree218af72ec2be4c310223bfc1b4df622e9769d79e
parentb065063c570f8dfb25eccb5094fef7e89a1883f2
upload-pack: accept only a single packfile-uri line

When we see a packfile-uri line from the client, we use
string_list_split() to split it on commas and store the result in a
string_list.  A single packfile-uri line is therefore limited to storing
~64kb, the size of a pkt-line.

But we'll happily accept multiple such lines, and each line appends to
the string list, growing without bound.

In theory this could be useful, making:

  0017packfile-uris http
  0018packfile-uris https

equivalent to:

  001dpackfile-uris http,https

But the protocol documentation doesn't indicate that this should work
(and indeed, refers to this in the singular as "the following argument
can be included in the client's request"). And the client-side
implementation in fetch-pack has always sent a single line (JGit appears
to understand the line on the server side but has no client-side
implementation, and libgit2 understands neither).

If we were worried about compatibility, we could instead just put a
limit on the maximum number of values we'd accept. The current client
implementation limits itself to only two values: "http" and "https", so
something like "256" would be more than enough. But accepting only a
single line seems more in line with the protocol documentation, and
matches other parts of the protocol (e.g., we will not accept a second
"filter" line).

We'll also make this more explicit in the protocol documentation; as
above, I think this was always the intent, but there's no harm in making
it clear.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/gitprotocol-v2.txt
upload-pack.c