fetch-pack: be more precise in parsing v2 response
authorJonathan Tan <jonathantanmy@google.com>
Fri, 19 Oct 2018 22:54:04 +0000 (15:54 -0700)
committerJunio C Hamano <gitster@pobox.com>
Thu, 1 Nov 2018 05:30:22 +0000 (14:30 +0900)
commit5400b2a2d989a4f09e7f666a41efac9ee3936f10
tree5426f52b6806253cf57aa5f90a222aecf4d564c0
parentc4df23f7927d8d00e666a3c8d1b3375f1dc8a3c1
fetch-pack: be more precise in parsing v2 response

Each section in a protocol v2 response is followed by either a DELIM
packet (indicating more sections to follow) or a FLUSH packet
(indicating none to follow). But when parsing the "acknowledgments"
section, do_fetch_pack_v2() is liberal in accepting both, but determines
whether to continue reading or not based solely on the contents of the
"acknowledgments" section, not on whether DELIM or FLUSH was read.

There is no issue with a protocol-compliant server, but can result in
confusing error messages when communicating with a server that
serves unexpected additional sections. Consider a server that sends
"new-section" after "acknowledgments":

 - client writes request
 - client reads the "acknowledgments" section which contains no "ready",
   then DELIM
 - since there was no "ready", client needs to continue negotiation, and
   writes request
 - client reads "new-section", and reports to the end user "expected
   'acknowledgments', received 'new-section'"

For the person debugging the involved Git implementation(s), the error
message is confusing in that "new-section" was not received in response
to the latest request, but to the first one.

One solution is to always continue reading after DELIM, but in this
case, we can do better. We know from the protocol that "ready" means at
least the packfile section is coming (hence, DELIM) and that no "ready"
means that no sections are to follow (hence, FLUSH). So teach
process_acks() to enforce this.

Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch-pack.c
t/t5702-protocol-v2.sh