path: root/builtin/rev-parse.c
diff options
authorJonathan Tan <>2018-10-19 22:54:04 (GMT)
committerJunio C Hamano <>2018-11-01 05:30:22 (GMT)
commit5400b2a2d989a4f09e7f666a41efac9ee3936f10 (patch)
tree5426f52b6806253cf57aa5f90a222aecf4d564c0 /builtin/rev-parse.c
parentc4df23f7927d8d00e666a3c8d1b3375f1dc8a3c1 (diff)
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 <> Signed-off-by: Junio C Hamano <>
Diffstat (limited to 'builtin/rev-parse.c')
0 files changed, 0 insertions, 0 deletions